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

[Avi Kivity <avi@redhat.com>]

On 06/12/2011 10:21 PM, Anthony Liguori wrote:
>>
>>> 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).

I bus/device relationship is not imposed, but may hold for some of the 
devices (but not others).

Another example of aggregation is PCI slots and functions.  A PCI device 
is composed of multiple functions that can be hotplugged as one, and 
share parts of the address.  But there is no "slot/function bus" involved.

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

Agreed; and it's quite obvious as the bus has a RESET line but no 
relationship to live migration.

-- 
error compiling committee.c: too many arguments to function