Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/08/2011 01:30 PM, Aurelien Jarno wrote:
> On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
>    
>> Chris Wright<chrisw@redhat.com>  writes:
>>
>> [...]
>>      
>>> - qdev/vmstate both examples of partially completed work that need more
>>>    attention
>>>        
>> As far as qdev's concerned, I can see two kinds of to-dos:
>>
>> * Further develop qdev so that more of the machine init code can becomes
>>    qdev declarations.  Specific ideas welcome.  Patches even more, as
>>    always.
>>
>> * Convert the remaining devices.  They are typically used only with
>>    oddball machines, which makes the conversion hard to test for anyone
>>    who's not already using them.
>>
>>    I've said this before: at some point in time (sooner rather than
>>    later, if you ask me), we need to shoot the stragglers.  I'm pretty
>>    optimistic that any victims worth keeping will receive timely
>>    attention then.
>>
>>      
> For those oddball machines, qdev doesn't really bring anything, that's
> why there is so little interest in converting them, and why I prefer to
> spend my time on the emulation correctness than converting those
> remaining to qdev. Of course I agree it's something to do, and with an
> unlimited amount of free time, I'll do them immediately.
>
> Let's take for example the SH4 target. It's nice to be able to create
> the whole machine from a script, except your kernel won't boot if the
> machine:
> - has a different cpu
> - doesn't a SM501 chipset
> - has not the correct memory size
> - doesn't have 2 serial port
>    

qdev needs a v2.  The object model is very difficult to work with and it 
offers little value for the scenario you describe.

A SoC should be modelled as a single object with parameters that can be 
set.  That object will then have other objects embedded through it with 
composition or reference.

So for instance, you might have:

class SH4 {
     SH4CPU cpu[n_vcpus];
     SM501 chipset;
};

class SM501 : public PCIHostController {
      PCIDevice *slots[32];
};

Having a script where you describe this is wrong.  This ought to be an 
object.  For instance, what we really ought to have on x86 is:

qemu -no-machine -device i440fx,id=root -device 
rtl8139,bus=/root/pci.0,addr=1.0 -device cpu,chipset=/root

Part of the problem with qdev v1 is that it doesn't allow for meaningful 
object composition.  The only relationship between devices is through 
BusState which presents a hierarchical parent/child relationship.

We really need a way to do composition and referencing.  For instance, 
if you notice above, SM501 has 32 references to a PCIDevice as opposed 
to having a linked list of children.  The effect is that a PCIDevice 
does not have the PCIHostController as it's "parent" because there's no 
intrinsic parent/child hierarchy.

So really, we're talking about a device graph here instead of a tree.

Regards,

Anthony Liguori

> That basically only leaves the PCI and USB devices configurable, but
> those are already using qdev.
>
>