On Wed, Jul 25, 2018 at 06:22:17PM +0800, Hongbo Zhang 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)
virtio-pci has nothing to do with *HCI. You're adding an E1000e to the PCIe bus instead of a virtio-pci nic. Why? > 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. Right. The new firmwares and kernels would need to include virtio-pci nic and scsi drivers. Is that a problem? Anyway, this is all the more reason not to hard code peripherals. If a particular peripheral is a problem for a given firmware, then simply don't add it to the command line, add a different one. > > >> - 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. Hmm. I thought for real hardware that the ACPI tables were built into the firmware. So, assuming UEFI knows how to read ACPI tables from some storage, then how do the QEMU generated ACPI tables get into that storage? > If we develop firmware depends on paravirtualized device like fw_cfg, > then we canot run such firmware on real hardware. Yes, fw-cfg is paravirt, so it's obvious why you'd prefer it not be there, but, where real hardware builds its hardware descriptions into its platform-specific firmware, or uses some platform-specific means of extracting a description from some platform-specific place, QEMU machine models use fw-cfg. Thanks, drew
