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: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices
Date: Fri, 10 Jun 2011 09:45:29 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10

On 06/10/2011 09:22 AM, Markus Armbruster wrote:
Peter Maydell<address@hidden>  writes:

But I think that's a non-typical case compared to the usual one
of "these wires are just hardwired this way by the machine".

IIRC, the PCI bus also provides a number of IRQ lines for the device to
tickle (INTA#..INTD#).  There's rarely a need to configure their use,
though.

Right.  So a PCI bus has 4 Pins (ignoring MSI) that a device can connect to.

This is a case where Pin is the wrong interface to model because the device decides which LNK to use. We don't want to model every single wire with a 32-bit PCI bus such that we have to make dozens of connections. We want to collapse all into a single higher level interface:

So you want something like:

 -device i440fx,id=pcibus,slot[3]=blk0
 -device virtio-pci-blk,id=blk0,bus=pcibus

And then when the virtio-pci-blk device is "realized" (qdev_initfn), it should use it's bus property and connect to the appropriate LNKs.

You could do the same for ISA, but since it's so common to have DIP switches on non-PnP ISA devices, and we call things ISA that aren't strictly ISA (yeah, yeah, let's not have this discussion again), actually wiring up the IRQs by hand instead of having it negotiated through the bus interface makes sense.

But note that the use of "bus" here is just a name. It does not implement the notion of bus that qdev does and says nothing about device hierarchy.

Regards,

Anthony Liguori




reply via email to

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