On 26/03/19 08:00, Xiao Guangrong wrote: > On 3/26/19 7:18 AM, Paolo Bonzini wrote: >> Also, what is the use case? Is it to reduce the attack surface without >> having multiple QEMU binaries? > > Security is one story we concern， only the essential and audited > modules/libraries can be loaded into memory. > > Another story is that lightweight virt. becomes more and more important > to run VM-based workload in the public Cloud. However, QEMU is too huge > and cumbersome to fill our requirements, e.g, QEMU-lites has been being > developed for a long time but still lacks a way into mainline or > Intel's nEMU more radically.
What is your definition of lightweight? To some extent, moving devices to separate dynamic libraries _adds_ weight for the mechanisms to load those libraries dynamically. Would separate QEMU binaries be a solution? I think I am not as opposed to a "q35-lite" machine type these days, I find it preferrable to share the northbridge and southbridge with Q35 and just get rid of IDE, VGA, IOAPIC, legacy ISA devices etc. The chipset would stay the same as q35 so that we keep secure boot, share the code for ACPI stuff (hotplug), and if the OS needs it we can also add back the RTC. Paolo
