qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Xiao Guangrong
Subject: Re: [Qemu-devel] About making QEMU to LIBs!
Date: Tue, 26 Mar 2019 17:28:26 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3



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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]