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

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Andrew Jones (drjones@redhat.com) 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.

I think the difference from last time is Ard's comments earlier in this
thread:

    The purpose of the SBSA machine is not to provide a minimal
    configuration. It is intended to exercise all the moving parts one
    might find in a server firmware/OS stack, including pieces that are
    not usually found on x86 machines, such as DRAM starting above 4 GB
    and SATA/USB controllers that are not PCIe based.

that suggests that the intent of this board is to provide everything
which a firmware writer might want to test;  that's quite different
from forming the basis of a virtualised machine for real use.

Dave


> >  - 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.
> 
> Thanks,
> drew
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK