Re: [Qemu-devel] About making QEMU to LIBs!

[Xiao Guangrong]

On 3/26/19 5:07 PM, Paolo Bonzini wrote:
> 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.

Lightweight = less resource usage + fast to reach user's self-defined workload.

For the new software, these libraries can be statically linked into it.

> Would separate QEMU binaries be a solution?  I think I am not as opposed

Separate QEMU binaries mean we need multiple different compiling environments
and additional package maintenance on the production...

> 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.

Well, that is a big step forward. :)

I'd think making most used components, such as virtio devices, are statically
compiled that is the minimal requirements for lightweight scenario. Other
components are libraries which can be dlopen() at the runtime, that slow
little down to boot the traditional VMs indeed but that is acceptable...