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

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/13/2011 03:05 AM, Avi Kivity wrote:
> 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.

Correct.

This also hints at how hot plug could work.  If devices had properties 
of type socket that you could connect devices too, a device could 
conceivably lock the socket after the device is realized (becomes guest 
visible).

Sockets that aren't locked after realize are hot pluggable.  Hot 
plugging simply becomes making a connection post realize.  An address is 
implied by the property path.

This gives you a way to allow PCI devices to be plugged in sockets 
(including multifunction devices) while not allowing individual 
functions to be hot plugged.

Regards,

Anthony Liguori

Regards,

Anthony Liguori