Re: [Qemu-arm] [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type

[Ard Biesheuvel]

On 26 July 2018 at 09:35, Hongbo Zhang <address@hidden> wrote:
> On 25 July 2018 at 18:53, Dr. David Alan Gilbert <address@hidden> wrote:
>> * Hongbo Zhang (address@hidden) wrote:
>>> On 25 July 2018 at 17:54, Andrew Jones <address@hidden> wrote:
>>> > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote:
>>> >> For the Aarch64, there is one machine 'virt', it is primarily meant to
>>> >> run on KVM and execute virtualization workloads, but we need an
>>> >> environment as faithful as possible to physical hardware, for supporting
>>> >> firmware and OS development for pysical Aarch64 machines.
>>> >>
>>> >> This patch introduces new machine type 'Enterprise' with main features:
>>> >>  - Based on 'virt' machine type.
>>> >>  - Re-designed memory map.
>>> >>  - EL2 and EL3 are enabled by default.
>>> >>  - GIC version 3 by default.
>>> >>  - AHCI controller attached to system bus, and then CDROM and hard disc
>>> >>    can be added to it.
>>> >>  - EHCI controller attached to system bus, with USB mouse and key board
>>> >>    installed by default.
>>> >>  - E1000E ethernet card on PCIE bus.
>>> >>  - VGA display adaptor on PCIE bus.
>>> >>  - Default CPU type cortex-a57, 4 cores, and 1G bytes memory.
>>> >>  - No virtio functions enabled, since this is to emulate real hardware.
>>> >
>>> > In the last review it was pointed out that using virtio-pci should still
>>> > be "real" enough, so there's not much reason to avoid it. Well, unless
>>> > there's some concern as to what drivers are available in the firmware and
>>> > guest kernel. But that concern usually only applies to legacy firmwares
>>> > and kernels, and therefore shouldn't apply to AArch64.
>>> >
>>> In real physical arm hardware, *HCI are system memory mapped, not on PCIE.
>>> we need a QEMU platform like that. We need firmware developed on this
>>> QEMU platform can run on real hardware without change(or only a minor
>>> change)
>>
>> How would you deal with most modern hardware now using XHCI rather than
>> EHCI ?
>>
> Well, EHCI still works well on server, some new X86 servers have both
> XHCI and EHCI, Qualcomm Centriq Arm server even has only EHCI, so
> currently only the EHCI is added.
> I had no strong reason for XHCI or EHCI, if newer is better or some
> users have special requirement for XHCI, it can be added too.
>

Does that really matter? As I pointed out before, we are not
interested in running the firmware on actual bare metal. What we do
care about is not having code in the reference firmware stack that was
added specifically to deal with the dynamic nature of our QEMU
platform.