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

[Stefano Garzarella]

On Thu, Mar 28, 2019 at 02:45:37PM +0800, Xiao Guangrong wrote:
> On 3/27/19 5:41 PM, Stefano Garzarella wrote:
> > 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.
> > 
> 
> Hi Stefan Hajnoczi and Stefano Garzarella,
> 
> The work exploring the QEMU modules looks really good. we will
> evaluate it.
> 
> Hmm... how about make these modules usable out of QEMU, it seems
> doable, right? But I'm not sure how much effort we need.

What use case do you have in mind?
These modules use several QEMU internal APIs, so you should provide all
of them.

> 
> > 
> > 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 :)
> 
> Great work, Stefano!

Thanks :)

> 
> Does the benefit come from the fact that your work avoids load some
> libraries during exec(), right? So it depends on the size of the
> shared library?
> 

Partially. The benefit also depends of the time needed in the init
functions of those libraries (__attribute__((constructor))) that in some
cases requires a lot of time, but I would consider also the size of
libraries.

Thanks,
Stefano