On 25 July 2018 at 17:54, Andrew Jones <drjo...@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. > For Armv7, there is one typical platform 'vexpress', but for Armv8, no such typical one, the 'virt' is typically for running workloads, one example is using it under OpenStack. So a 'typical' one for Armv8 is needed for firmware and OS development, similar like 'vexpress' for Armv7.
>> - 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