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

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

On 06/10/2011 03:13 AM, Markus Armbruster wrote:
> Jan Kiszka<jan.kiszka@siemens.com>  writes:
>> 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.

More specifically, a device has input IRQs.  A device has no idea what 
number the IRQ is tied to.

Devices may also have output IRQs.  At the qdev layer, we should be able 
to connect an arbitrary output IRQ to an arbitrary input IRQ.

So the crux of the problem is that:

  -device isa-serial,id=serial,irq=3

Is very wrong.  It ought to look something more like

  -device piix3,id=piix3 -device isa-serial,id=serial,irq=piix3.irq[3]

IRQ forwarding becomes very easy in this model because your composite 
qdev device has a set of input IRQs and then routes the input IRQs to 
the appropriate input IRQs of the sub devices.

The trouble is that I don't think we have a reasonable way to refer to 
properties of other devices and we don't have names for all devices.  I 
think if we fix the later problem, the former problem becomes easier.

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

That's just syntactic sugar.  It can live at a higher level than the 
qdev API.

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

They pretty much are.  We're really just talking about referring to 
subcomponents of a device.  That's what's lacking today.

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

Busses need to die.  They can be replaced by having fixed "slots".  For 
instance, if you had a way of having a PCIDevice * property, the I440FX 
could have 32 PCIDevice * properties.  That's how you would add to a bus 
(and notice that it conveniently solves bus addressing in a robust fashion).

Regards,

Anthony Liguori

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