Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices

[Anthony Liguori <aliguori@us.ibm.com>]

On 06/12/2011 12:12 PM, Avi Kivity wrote:
> On 06/10/2011 06:43 PM, Anthony Liguori wrote:
>>
>>> What exactly is so very wrong about buses that they need to die?
>>
>> They force a device tree. The device model shouldn't be a tree, but a
>> directed graph.
>
> Right. As an example, you configure PCI interrupt routing and the memory
> controller by writing to a PCI device, which logically doesn't have
> access to any of this stuff if it's behind the PCI bus.
>
> However, I don't think buses should die. They should be available as an
> easy way to model the devices that do follow the rules. But we should
> also expose everything else for the exceptional cases.
>
>> It's perfectly fine to have a type called PCIBus that I440FX extends,
>> but qdev shouldn't have explicit knowledge of something called a "bus"
>> IMHO. Doing this forces a limited mechanism of connecting devices
>> because it creates an artificial tree (by implying a parent/child
>> relationship). It makes composition difficult if not impossible.
>
> I think qdev buses are useful as long as they don't enforce their
> interfaces. That is, a qdev that is a child of a qbus has access to the
> qbus's interfaces, but also access to other stuff.

I see two independent data structures.  The first is the "instantiation 
tree".

The instantiation tree may look like this:

+-- i440fx
|  |
|  +-- PIIX3
|  |  |
|  |  +-- mc146818a
|  |  +-- uart
|  |  +-- DMA
|  |  +-- keyboard controller
|  |  +-- (remaining platform ISA devices
|  |
|  +-- UHCI USB controller
|  +-- IDE controller
|
+-- e1000
+-- cirrus-vga
+-- virtio-balloon-pci
+-- IDE disk0

Instantiating i440fx makes a bunch of default stuff.  This is 
composition.  Everything else requires explicit instantiation.  This is, 
strictly speaking, the parent/child relationships.  If you destroy 
i440fx, all of it's children have to also go away (by definition). 
Nothing about bus relationship is implied here.  Even if i440fx exposes 
a PCI bus, the PIIX3 is a child of i440fx even though e1000 is not (even 
if they're both PCI devices).

That said, there absolutely should be the following paths:

/i440fx/IDE controller/primary/master -> IDE disk0
/i440fx/slot3 -> cirrus-vga

The expression of bus should just be a bidirectional path (when that 
makes sense).  IOW:

/i440fx/slot3 -> cirrus-vga
/cirrus-vga/bus -> i440fx

There, of course, can be all sorts of crazy paths through the graph. 
The following should be valid:

/i440fx/slot2 -> IDE controller
/cirrus-vga/bus/slot2/primary/master

But separating out hw paths from instantiation tree has some nice 
characteristics.  The instantiation tree is the obvious place to 
implement live migration whereas reset would probably walk device paths.

Regards,

Anthony Liguori