Hi Yang, Xiao,
Just adding few things, because I'm currently exploring the QEMU modules
in order to reduce the boot time and the footprint.
On Tue, Mar 26, 2019 at 09:27:09AM +0000, Stefan Hajnoczi wrote:
> On Tue, Mar 26, 2019 at 03:00:05PM +0800, Xiao Guangrong wrote:
> > 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.
>
> QEMU's build system supports dynamically loaded "modules" (shared
> libraries). You can build all features but only load a subset of them
> at runtime. You can also install just a subset of modules on a host.
>
> Examples are the block drivers and audio drivers. See ./configure and
> block/Makefile.objs. QEMU's build system has 'y', 'n', and 'm' (for module).
>
> So far no emulated devices are built as modules, but this would be a
> good area to explore.
>
The idea is to create new QEMU modules (like the block/audio/ui
drivers) in order to reduce the dependency of QEMU executable to the
shared libraries that require a lot of time for the initialization, so
we can postpone their initialization only when we will use them.
Using callgrind I'm profiling the loading of dynamic libraries to
understand which part of QEMU should be modularized to speed up the boot
phase when they are not used.
I found that libgnutls, libspice-server and libnuma initialization takes
most of the time. I disabled these libraries (--disable-numa --disable-gnutls
--disable-spice) to understand the maximum speed up and I gained 10 ms
during the boot:
- qemu_init_end: 50.92 ms
- qemu_init_end: 40.17 ms (without numa, gnutls and spice)
I would start to modularize spice, the library is used in the spice
drivers (spice-display, spice-chardev, spice-input, etc.) but also in
the QXL emulation.
Maybe we can synchronize our work :)
Cheers,
Stefano
