Re: [Qemu-devel] [RFC] QEMU Object Model

[Anthony Liguori]

On 07/21/2011 10:04 AM, Avi Kivity wrote:
> On 07/21/2011 05:49 PM, Anthony Liguori wrote:
> > On 07/21/2011 08:38 AM, Avi Kivity wrote:
> > > On 07/21/2011 04:20 PM, Anthony Liguori wrote:
> >
> > > > static TypeInfo tcp_server_type_info = {
> > > > .name = TYPE_TCP_SERVER,
> > > > .parent = TYPE_SOCKET_SERVER,
> > > > .instance_size = sizeof(TcpServer),
> > > > .instance_init = tcp_server_init,
> > > > .class_init = tcp_server_class_init,
> > > > };
> > >
> > > How do the properties become registered? Ah, I see you do have to
> > > register them. You'd have to do the same in C++, but it would be a lot
> > > simpler and type-safer (you can use pointers to members, for example,
> > > and avoid getter/setters where unnecessary).
> >
> > See git://git.codemonkey.ws/kvm++.git
>
> Connection refused..

Sorry, stupid EC2.  Try http://git.codemonkey.ws/git/kvm++.git


> > It's exactly the same object model, but in C++. Some things are nicer,
> > some things are not nicer. It's not quite a slam dunk.
> >
> > But what really concerned me about it was that I quickly realized that
> > it was going to be mostly write-only code. The C++ tricks that you
> > need to do to make it all work well are extremely obscure. It requires
> > template meta-programming, every obscure detail about partial
> > specialization, etc.
>
> Yes, that's a big worry. Is all of that exposed to the implementer? Or
> just in the framework?

I was able to get it mostly hidden but not entirely.  The biggest 
problem is that even with a semi normal looking function, a simple 
mistake like passing in the wrong number of arguments can result in an 
undecipherable error message.  It's not bad to debug if you're used to 
it but very difficult to just slip in to a C project.

> > > There is quite a lot of boilerplate - around half the code of tcp.[ch].
> > > It may be simple to create a new type to the author of the framework,
> > > but I doubt it would be simple to others. There would be a lot of
> > > cut'n'paste.
> >
> > Yup. That's the price you pay for using C over C++. But the ratio is
> > only true for simple types. Complex types (look at chrdrv.h), the
> > ratio is much lower.
>
> chrdrv.c is almost 100% boilerplate.

Sure, but so is qemu-char.c and block.c.  It's not really different from 
what we have today.

> > > We can change the language first.
> >
> > My view is roughly this:
> >
> > 1) introduce type system and update build system
> >
> > 2) convert each backend, add compatibility handlers to preserve
> > existing monitor commands and command line arguments. deprecate
> > everything to be removed in qemu 2.0.
> >
> > 3) introduce a new front end written in Python that only works with
> > the plug interfaces
> >
> > 4) convert the device model. compatibility will be hard to maintain
> > but I think it's doable.
> >
> > 5) declare qemu 2.0, remove all of the compatibility stuff, and
> > potentially move it to a new python script for legacy usage.
>
> The big problem with this plan is that steps 2 and 4 are very difficult
> and yet we see no gains while it's being done.

So at least with the chardev conversion, we'll get the ability to 
dynamically add character devices and change the settings of a chardev 
after start up.  Both of these are important features.

I think done properly, it all can have incremental value.  I worry about 
converting the device model.

> A much smaller job (the
> memory API conversion) is turning out to be no fun at all.

Yeah, I don't know how to fix that.  This is why I'm starting with the 
backends.  They're much smaller than the device model.

> > At this point, qemu would no longer be an executable that was directly
> > invoked by a user. They would use a wrapper script to provide the
> > functionality of today's qemu. Management software could launch the
> > daemon on their own.
> >
> > C++ doesn't eliminate any of these steps. IMHO, it doesn't
> > tremendously simplify any of these steps either.
>
> It trades off a lot of boilerplate (translated to copy'n'paste with all
> its issues) into 20-line error messages. Inheriting from a class and
> implementing all of its pure virtuals is a lot easier than doing the C
> equivalent.

Agreed re: the trade offs.

> > I think *good* C++ could provide some value by eliminating the
> > possibility of buffer overflows, use-after-free, memory-leaks, etc.
> > But that's icing on the cake.
>
> Yes.
>
> > I don't ever see the device model being written in something other
> > than C/C++ too. Having a GC in the VCPU thread would be a major issue
> > IMHO.
>
> We get the equivalent of GC every time a vcpu thread is scheduled out so
> an iothread or an unrelated process can run.

But you can control this with pinning, priorities, etc.  You cannot with GC.

And in quite a lot of systems, GC pauses are very, very long.

> It will hurt hard realtime
> guests, but these are only interesting to a small subset of users.
>
> I think that if we can get the data path to run in pure C, and have the
> GC HLL involved only when the device model is reconfigured, then we have
> an acceptable tradeoff. I don't claim that I know how to do this,
> though. This is a really hard problem, mostly due to the huge size of qemu.

This is one very good thing about having a common object model that's 
pluggable (which is what QOM is all about).  It becomes relatively easy 
to build with CONFIG_PCI=n, then build a shared library that implements 
a new PCI layer in your favorite HLL so that you can experiment.

Regards,

Anthony Liguori