* Hongbo Zhang (hongbo.zh...@linaro.org) wrote: > 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. > > > 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 / dgilb...@redhat.com / Manchester, UK
