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

[Blue Swirl]

On Wed, Feb 9, 2011 at 12:43 PM, Anthony Liguori <address@hidden> wrote:
> 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<address@hidden>  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.

That is actually how hardware is usually designed, usually multiple
active masters or cyclic graphs would be too complex.

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

I think the problem is that there are several semi-overlapping trees
when you take into consideration also IRQ routing, power lines, wakeup
signals etc. and this is not so easy to describe.