On Wed, Feb 9, 2011 at 12:43 PM, Anthony Liguori <anthony@xxxxxxxxxxxxx> 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<chrisw@xxxxxxxxxx> Â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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
