Paolo Bonzini writes: > On 25/07/19 15:26, Stefan Hajnoczi wrote: >> The microvm design has a premise and it can be answered definitively >> through performance analysis. >> >> If I had to explain to someone why PCI or ACPI significantly slows >> things down, I couldn't honestly do so. I say significantly because >> PCI init definitely requires more vmexits but can it be a small >> number? For ACPI I have no idea why it would consume significant >> amounts of time. > > My guess is that it's just a lot of code that has to run. :( I think I haven't shared any numbers about ACPI. I don't have details about where exactly the time is spent, but compiling a guest kernel without ACPI decreases the average boot time in ~12ms, and the kernel's unstripped ELF binary size goes down in a whooping ~300KiB. On the other hand, removing ACPI from QEMU decreases its initialization time in ~5ms, and the binary size is ~183KiB smaller. IMHO, those are pretty relevant savings on both fronts. >> Until we have this knowledge, the premise of microvm is unproven and >> merging it would be premature because maybe we can get into the same >> ballpark by optimizing existing code. >> >> I'm sorry for being a pain. I actually think the analysis will >> support microvm, but it still needs to be done in order to justify it. > > No, you're not a pain, you're explaining your reasoning and that helps. > > To me *maintainability is the biggest consideration* when introducing a > new feature. "We can do just as well with q35" is a good reason to > deprecate and delete microvm, but not a good reason to reject it now as > long as microvm is good enough in terms of maintainability. Keeping it > out of tree only makes it harder to do this kind of experiment. virtio > 1 seems to be the biggest remaining blocker and I think it'd be a good > thing to have even for the ARM virt machine type. > > FWIW the "PCI tax" seems to be ~10 ms in QEMU, ~10 ms in the firmware(*) > and ~25 ms in the kernel. I must say that's pretty good, but it's still > 30% of the whole boot time and reducing it is the hardest part. If > having microvm in tree can help reducing it, good. Yes, it will get > users, but most likely they will have to support pc or q35 as a fallback > so we could still delete microvm at any time with the due deprecation > period if it turns out to be a failed experiment. > > Whether to use qboot or SeaBIOS for microvm is another story, but it's > an implementation detail as long as the ROM size doesn't change and/or > we don't do versioned machine types. So we can switch from one to the > other at any time; we can also include qboot directly in QEMU's tree, > without going through a submodule, which also reduces the infrastructure > needed (mirrors, etc.) and makes it easier to delete it. > > Paolo > > (*) I measured 15ms in SeaBIOS and 5ms in qboot from the first to the > last write to 0xcf8. I suspect part of qboot's 10ms boot time actually > end up measured as PCI in SeaBIOS, due to different init order, so the > real firmware cost of PAM and PCI initialization should be 5ms for qboot > and 10ms for SeaBIOS.