qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices
Date: Fri, 10 Jun 2011 16:59:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 06/10/2011 03:13 AM, Markus Armbruster wrote:
>> Jan Kiszka<address@hidden>  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]

As Jan pointed out, ISA is a counter-example: your "very wrong" claim is
actually wrong there :)

An ISA device is always connected to all the ISA bus's interrupt lines.
Device configuration determines how the device uses these lines.

The old (non-MSI) PCI interrupts are similar, I think.

Of course, "ISA IRQ 4" can be anything, depending on how the device
providing the ISA bus is wired up.

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

We already connect devices to other resources, such as block, char and
network host parts.  The way we do it may not be "pure", but it works:
we define the plug as property, and connect it to its socket by saying
PROP-NAME=SOCK-NAME.  Note that the connection is made by core qdev;
device model code is oblivious of it.  It just uses it.

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

Well, I wish I was as certain as you about about what is very wrong,
what needs to die, and what needs to be done instead.

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

Assumes that bus addresses are isomorphic to [0..N], doesn't it?

Not really the case for USB: we use a string of the form %d(.%d)* there.
Not my idea.

A bus is just a standardized container for slots.  A single device can
provide multiple buses.  Killing buses just unwraps the slots.  You lose
the grouping.

What exactly is so very wrong about buses that they need to die?
Honest, non-rhetorical question.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]