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

[Markus Armbruster]

Jan Kiszka <address@hidden> writes:

> On 2011-06-09 18:40, Markus Armbruster wrote:
>> Jan Kiszka <address@hidden> writes:
>> 
>>> On 2011-06-08 13:33, Peter Maydell wrote:
>>>> At the moment you can't really implement one sysbus device by saying
>>>> that it's composed of a set of other sysbus devices. This patch adds
>>>> new functions sysbus_pass_mmio() and sysbus_pass_one_irq() which
>>>> allow a sysbus device to delegate an MMIO or IRQ to another sysbus
>>>> device (The approach is inspired by the existing sysbus_pass_irq()
>>>> which lets a sysbus device delegate all its IRQs at once).
>>>>
>>>> This works; the most obvious deficiency is that the subcomponent
>>>> device will still appear as its own device on the bus.
>>>>
>>>> So: is this a reasonable solution to the problem, or an unacceptable
>>>> hack? Comments welcome :-)
>>>
>>> Sounds more like a little hack. :)
>>>
>>> The relationships should be expressed via qdev, not yet another
>>> sysbus-specific extension. Generally, many services of sysbus should
>>> rather be generic qdev things.
>> 
>> Examples?
>
> Resource management, e.g. IRQs. That will be useful for other types of
> buses as well.

A device should be able to say "I need to be connected to an IRQ line".
Feels generic to me.

A device or bus should be able to offer IRQ lines.  Feels generic, too.

Connecting the two is configuration.  Requires a suitable naming scheme
for IRQ lines.  Naming might have to include bus-specific sugar for
user-friendliness.  For instance, I'd rather express "isa-serial uses
ISA interrupt 4" as "irq=4" than as something like
"irq=PIIX3/isa.0:irq.4".

I doubt all resources are as generic as IRQ lines, but that's okay.

>>> Is there anything that today prevents creating a local bus and attaching
>>> the component devices to that? If it's multi-bus support, that should to
>>> be added anyway. Passing-through of MMIO and IRQs is still a worthwhile
>>> generic service, then probably qbus associated.
>> 
>> Do you mean making the container device a sysbus-sysbus-bridge, then
>> hanging the component devices off the inner sysbus?
>
> And how to apply this concept on a composed PCI device e.g.?

Make the PCI device provide a sysbus for its components?  Dunno...

See also thread "[RFC v4 00/12] ISA reconfigurability v4".

> Maybe we could define something like Linux' struct resource + a set of
> helper services for it.

Device component composition is not (yet?) covered by qdev.  Of course
we compose anyway, in various ad hoc ways.

One way is to put the components' state structs into the device's state
struct, and define suitable wrappers.  For instance, we have qdevs
"sysbus-fdc" and "isa-fdc".  They both contain the FDC proper as a
component: FDCtrlSysBus and FDCtrlISABus contain a FDCtrl member.
Simple enough.

A different way to adapt the same component to different buses can be
found in virtio: VirtIOPCIProxy and VirtIOS390Device both contain
pointers to VirtIODevice.  I found that one quite awkward to work with.

Yet another way can be found in usb-storage.  usb-storage expands into
two qdevs connected by a qbus: it provides a SCSI bus, and automatically
creates a single scsi-disk on that bus.  One of those tricks that look
cute initially, then create no end of trouble.

I figure a "qdevy" composition mechanism would be useful.  Needs
thought.