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

[Xiao Guangrong]

On 3/26/19 7:18 AM, Paolo Bonzini wrote:
> On 25/03/19 12:46, Yang Zhong wrote:
> > Hello all,
> >
> > Rust-VMM has started to make all features and common modules to crates, and CSP 
> > can
> > deploy their VMM on demand. This afternoon, Xiao guangrong and i talked about 
> > the light
> > weight VM solitions，and we thought QEMU can do same thing like Rust-vmm, 
> > although we can
> > make all modules or features in QEMU configurable, but making features and 
> > modules to libs
> > are still valuable for QEMU. Any comments are welcome! thanks!
>
> What features/modules were you thinking of?  Were you thinking of
> turning them into dynamically loaded libraries, or spinning them out
> into separate projects (such as libslirp)?

We are considering make QEMU's device emulations to dynamically libraries that 
include
virtio devices, IO controller and even vCPU emulations plus some hooks into it, 
and so
on.

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

That's why we are going to redesign the userspace VMM, making QEMU to libraries 
is
definitely good to us.

> Having dynamically linked libraries would go even beyond what rust-vmm
> does; Rust binaries in the end statically link every crate that they
> use, rust-vmm's purpose is mostly to share code across VMMs and avoid
> forks.  It may also have a startup time penalty which has to be considered.

Rust-VMM is good indeed, but it's not friendly enough for us.

QEMU IS A GOOD GUY，no reason to abandon it. :)

QEMU is excellent and we are using it in our productions for so many years, its 
code
is trusted as robust. Reusing QEMU's code helps the new software to achieve
production-level's quality.

Furthermore, we still need QEMU for the traditional workloads, maintaining two 
totally
different code base is not easy for the cloud provider and most developers in 
the cloud
companies are really good at QEMU. So leveraging QEMU and the new software is 
more
convenient for us.

Thanks!