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

Anthony Liguori
2011-02-09T10:44:55Z

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