On 25/07/19 12:42, Sergio Lopez wrote: > > Peter Maydell <peter.mayd...@linaro.org> writes: > >> On Thu, 25 Jul 2019 at 10:59, Michael S. Tsirkin <m...@redhat.com> wrote: >>> OK so please start with adding virtio 1 support. Guest bits >>> have been ready for years now. >> >> I'd still rather we just used pci virtio. If pci isn't >> fast enough at startup, do something to make it faster... > > Actually, removing PCI (and ACPI), is one of the main ways microvm has > to reduce not only boot time, but also the exposed surface and the > general footprint. > > I think we need to discuss and settle whether using virtio-mmio (even if > maintained and upgraded to virtio 1) for a new machine type is > acceptable or not. Because if it isn't, we should probably just ditch > the whole microvm idea and move to something else.
I agree. IMNSHO the reduced attack surface from removing PCI is (mostly) security theater, however the boot time numbers that Sergio showed for microvm are quite extreme and I don't think there is any hope of getting even close with a PCI-based virtual machine. So I'd even go a step further: if using virtio-mmio for a new machine type is not acceptable, we should admit that boot time optimization in QEMU is basically as good as it can get---low-hanging fruit has been picked with PVH and mmap is the logical next step, but all that's left is optimizing the guest or something else. I must say that -M microvm took a while to grow on me, but I think it's a great example of how the infrastructure provided by QEMU provides useful features for free, even for the simplest emulated hardware. For example, in v3 microvm could only boot from PVH kernels, but the next firmware-enabled version reuses more of the PC code and thus supports all of vmlinuz, multiboot and PVH. Again: Sergio has been very receptive to feedback and has provided numbers to back the design choices, and we should reciprocate or at least be very clear on the constraints. Paolo