|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] KVM call minutes for Feb 8 |
Date: | Wed, 09 Feb 2011 04:43:33 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10 |
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 attentionAs 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.
[Prev in Thread] | Current Thread | [Next in Thread] |