qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Anthony Liguori" <aliguori@us.ibm.com>,
	"Juha Riihimäki" <juha.riihimaki@nokia.com>,
	"patches@linaro.org" <patches@linaro.org>,
	"Jan Kiszka" <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Paul Brook" <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices
Date: Fri, 10 Jun 2011 09:45:29 -0500	[thread overview]
Message-ID: <4DF22E09.6030605@codemonkey.ws> (raw)
In-Reply-To: <m38vt9yddq.fsf@blackfin.pond.sub.org>

On 06/10/2011 09:22 AM, Markus Armbruster wrote:
> Peter Maydell<peter.maydell@linaro.org>  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	other threads:[~2011-06-10 14:45 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-08 11:33 [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices Peter Maydell
2011-06-08 11:33 ` [Qemu-devel] [PATCH RFC 1/3] sysbus: Add support for resizing and unmapping MMIOs Peter Maydell
2011-06-08 11:33 ` [Qemu-devel] [PATCH RFC 2/3] sysbus: Allow sysbus MMIO passthrough Peter Maydell
2011-06-08 11:33 ` [Qemu-devel] [PATCH RFC 3/3] sysbus: Allow passthrough of single IRQ Peter Maydell
2011-06-08 12:29 ` [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices Jan Kiszka
2011-06-09 16:40   ` Markus Armbruster
2011-06-09 17:03     ` Jan Kiszka
2011-06-10  8:13       ` Markus Armbruster
2011-06-10 12:51         ` Anthony Liguori
2011-06-10 13:10           ` Peter Maydell
2011-06-10 13:43             ` Jan Kiszka
2011-06-10 13:50               ` Peter Maydell
2011-06-10 14:22                 ` Markus Armbruster
2011-06-10 14:45                   ` Anthony Liguori [this message]
2011-06-10 14:34                 ` Anthony Liguori
2011-06-10 14:12               ` Anthony Liguori
2011-06-10 14:18                 ` Jan Kiszka
2011-06-10 14:31                   ` Anthony Liguori
2011-06-10 14:07             ` Anthony Liguori
2011-06-10 14:59           ` Markus Armbruster
2011-06-10 15:43             ` Anthony Liguori
2011-06-12 17:12               ` Avi Kivity
2011-06-12 19:21                 ` Anthony Liguori
2011-06-13  8:05                   ` Avi Kivity
2011-06-13 17:53                     ` Anthony Liguori
2011-06-13 20:59                   ` Blue Swirl
2011-06-14 13:21                     ` Anthony Liguori
2011-06-15 18:56                       ` Blue Swirl
2011-06-15 20:00                         ` Anthony Liguori
2011-06-15 20:20                           ` Blue Swirl
2011-06-20 15:23                             ` Paul Brook
2011-06-20 21:32                               ` Blue Swirl
2011-06-21  8:16                                 ` Avi Kivity
2011-06-27  2:26                                 ` Paul Brook
2011-06-13  9:57             ` Gleb Natapov
2011-06-10 16:28           ` Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DF22E09.6030605@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=juha.riihimaki@nokia.com \
    --cc=patches@linaro.org \
    --cc=paul@codesourcery.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).