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

[Avi Kivity <avi@redhat.com>]

On 07/21/2011 06:45 PM, Anthony Liguori wrote:
>>> See git://git.codemonkey.ws/kvm++.git
>>>
>>
>> Connection refused..
>
>
> Sorry, stupid EC2.  Try http://git.codemonkey.ws/git/kvm++.git

You don't have permission to access /git/kvm++.git/ on this server.

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

I have to agree with this.  You can write neat domain specific languages 
in C++ but the nice abstractions break the minute you misplace a comma.

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

I'm trying to get us away from boilerplate, actually writing the code 
that matters?

Maybe it's an unsolvable problem.  With a low level language, you get to 
write boilerplate.  With a high level language, the compiler writes it 
for you, and a whole lot more you don't want.

But it's a big problem.  Those conversions suck the life force out of 
whoever's doing them, and then he comes back as zombie to haunt us at 
the next kvm forum.  It's not just type safety at stake here.

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

Ok.  Let's hope you've hit on the least-bad tradeoff.  I'm sceptical, 
but I don't have anything concrete to offer.

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

I expect the number of objects we'll have will be very small (O(info qdm 
| wc -l)).  They'll also be very long lived.  Won't that make the GC 
rather fast?

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

If I wanted a new PCI layer I'd write one outside of qemu.  Getting PC 
emulation is probably easier than converting all of qemu - see tools/kvm 
(though they're not doing full emulation, just the subset needed to get 
Linux going).  I want the old layer, it has a lot of knowledge sweated 
into it and it's very compatible with itself and with the guests it has 
booted.

-- 
error compiling committee.c: too many arguments to function