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

[Dr. David Alan Gilbert]

* 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 ?

Dave

> Concern is not only available firmwares, but more emphasis is on new
> firmwares to be developed on this platform (target is developing
> firmware for hardware, but using qemu if hardware is not available
> temporarily), if virtio device used, then the newly developed firmware
> must include virtio front-end codes, but it isn't needed while run on
> real hardware at last.
> 
> >>  - No paravirtualized fw_cfg device either.
> >>
> >> Arm Trusted Firmware and UEFI porting to this are done accordingly.
> >>
> >
> > How will UEFI get the ACPI tables from QEMU without fw-cfg? I didn't
> > see any sort of reserved ROM region in the patch for them.
> >
> UEFI gets ACPI and kernel from network or mass storage, just like the
> real hardware.
> If we develop firmware depends on paravirtualized device like fw_cfg,
> then we canot run such firmware on real hardware.
> 
> > Thanks,
> > drew
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK