My colleague Marc Marí has been submitting a feature patch series to qemu-devel that exposes a DMA transfer-like interface for fw_cfg reads, based on a prototype by Gerd Hoffmann. This feature is available on both x86 and ARM guests, but their performance impact (and their use cases) are different.
(1) For x86, the performance boost is meager in absolute terms (less than a second) in single direct kernel boots: http://www.seabios.org/pipermail/seabios/2015-September/009757.html The performance boost is large however in relative terms, which is what matters for x86 -- because for x86, this feature is meant to help QEMU compete with light-weight container startup times. Halving the already fast SeaBIOS + direct kernel boot time is significant when one aims at many virtual machines that are expected to live only for a few seconds each. OVMF obviously doesn't try to participate in that race. Plus, on x86, KVM already has significant optimizations in place for the REP INSB instruction that we use in the Ia32 and X64 implementations of QemuFwCfgLib. Therefore this series doesn't contain x86-targeted code. (2) For ARM however, the savings are critical in absolute terms too. MMIO access is very costly on KVM-ARM; it translates to about 1500 KB/s fw_cfg download speeds on an APM Mustang, using the 8-byte wide MMIO data register of fw_cfg. This is fine for small fw_cfg items like the blobs used by the ACPI linker/loader and other config items, but not so fine when downloading a decompressed kernel and an initial ramdisk, weighing in at tens of megabytes, for direct kernel boot. (Direct kernel boot is possible without ArmVirtQemu; qemu-system-(arm|aarch64) can boot a kernel with a tiny firmware generated by QEMU on the spot. However, such a guest kernel will not have a UEFI environment, and in some situations such an environment is desirable. There are three common use cases: (a) testbed for kernel development that relates to UEFI, (b) installing a virtual machine from the network with the "virt-install --location ..." command, and (c) running the libguestfs appliance (= guest-side daemon of libguestfs) in a virtual UEFI environment.) The QEMU series is at v3: http://lists.nongnu.org/archive/html/qemu-devel/2015-09/msg04744.html Although it needs a few minuscule fixes, the interface has been finalized, and we've had great success testing the implementation. For example, I measured the fw_cfg download time of a kernel+initrd pair, sized 31MB in total, to drop from the original 24 seconds to about 52 milliseconds. http://lists.nongnu.org/archive/html/qemu-devel/2015-09/msg05030.html For another example, comparing ArmVirtQemu (aka. AAVMF) binaries built for "silent" operation (that is, with -D DEBUG_PRINT_ERROR_LEVEL=0x80000000), without and with this feature, Rich Jones measured the "guestfish" utility's launch time on an unloaded Mustang to drop from 18.9 seconds to 9 seconds -- without the feature, about half of the guestfish launch is spent in downloading the appliance kernel and initrd through fw_cfg. That download time can be reduced to tens of milliseconds with the QEMU feature and this matching ArmVirtPkg series, halving the guestfish launch time. The QEMU series has not been committed yet, but it's been converging nicely, and the interface is supposed to be stable, so I'm posting this (Marc has posted the x86 SeaBIOS client code too). Thanks Laszlo Cc: Ard Biesheuvel <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Drew Jones <[email protected]> Cc: "Richard W.M. Jones" <[email protected]> Cc: Marc Marí <[email protected]> Laszlo Ersek (2): ArmVirtPkg: VirtFdtDxe: detect fw-cfg DMA interface from the DTB ArmVirtPkg: QemuFwCfgLib: read bytes from fw-cfg with DMA when available ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf | 2 + ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf | 1 + ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 126 ++++++++++++++++++-- ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c | 15 +++ ArmVirtPkg/ArmVirtPkg.dec | 1 + ArmVirtPkg/ArmVirtQemu.dsc | 1 + ArmVirtPkg/ArmVirtXen.dsc | 1 + 7 files changed, 140 insertions(+), 7 deletions(-) -- 1.8.3.1 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
