qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laine Stump <laine@redhat.com>
To: marcel.a@redhat.com
Cc: qemu list <qemu-devel@nongnu.org>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] Attaching PCI devices to the PCIe root complex
Date: Wed, 25 Sep 2013 05:39:37 -0400	[thread overview]
Message-ID: <5242AF59.5060905@redhat.com> (raw)
In-Reply-To: <1380098908.1968.30.camel@localhost.localdomain>

On 09/25/2013 04:48 AM, Marcel Apfelbaum wrote:
> On Wed, 2013-09-25 at 10:01 +0300, Michael S. Tsirkin wrote:
>> On Tue, Sep 24, 2013 at 06:01:02AM -0400, Laine Stump wrote:
>>> When I added support for the Q35-based machinetypes to libvirt, I
>>> specifically prohibited attaching any PCI devices (with the exception of
>>> graphics controllers) to the PCIe root complex,
>> That's wrong I think. Anything attached to RC is an integrated
>> endpoint, and these can be PCI devices.
> I couldn't find on PCIe spec any mention that "Root Complex Integrated EndPoint"
> must be PCIe. But, from spec 1.3.2.3:
> - A Root Complex Integrated Endpoint must not require I/O resources claimed through BAR(s).
> - A Root Complex Integrated Endpoint must not generate I/O Requests.
> - A Root Complex Integrated Endpoint is required to support MSI or MSI-X or both if an
> interrupt resource is requested.

So much easier in the real world, where the rule is "if it fits in the
socket and the pins match up, then it's okay" :-)


>> IMO, we really need to grow an interface to query this kind of thing.
> Basically libvirt needs to know:
> 1. for (libvirt) controllers: what kind of devices can be plugged in

The controllers also need a flag indicating if they supporting having
devices hot-plugged into them. For example, as far as I understand, the
PCI root complex ("pcie-root" in libvirt) doesn't support hot-plugging
devices, nor does i82801b11-bridge ("dmi-to-pci-bridge" in libvirt), but
pci-bridge, ioh3420 ("root-port" in libvirt), and xio3130-downstream
("downstream-switch-port" in libvirt) *do* support hot-plugging devices
(as far as I know, none of these controllers can themselves be
hot-plugged into another controller, but that could change in the
future, e.g. I recall someone saying something about  hot-plug of a
pci-bridge being a future possibility)


> 2. for devices (controller is also a device)
>     - to which controllers can it be plugged in
>     - does it support hot-plug?
> 3. implicit controllers of the machine types (q35 - "pcie-root", i440fx - "pci-root")
> All the above must be exported to libvirt
>
> Implementation options:
> 1. Add a compliance field on PCI/PCIe devices and controllers stating if it supports
>    PCI/PCIe or both (and maybe hot-plug)
>    - consider plug type + compliance to figure out whether a plug can go into a socket
>    
> 2. Use Markus Armbruster idea of introducing a concept of "plug and sockets":
>    - dividing the devices into adapters and plugs
>    - adding sockets to bridges(buses?).
>    In this way it would be clear which devices can connect to bridges

However it is done, each controller will need to have two sets of flags
- one for what it can plug into, and one for what can be plugged into it.

  parent reply	other threads:[~2013-09-25  9:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-24 10:01 [Qemu-devel] Attaching PCI devices to the PCIe root complex Laine Stump
2013-09-25  7:01 ` Michael S. Tsirkin
2013-09-25  8:48   ` Marcel Apfelbaum
2013-09-25  8:59     ` Michael S. Tsirkin
2013-10-02  8:53       ` Paolo Bonzini
2013-10-02  9:28         ` Michael S. Tsirkin
2013-09-25  9:39     ` Laine Stump [this message]
2013-09-25 10:00       ` Michael S. Tsirkin
2013-09-25 10:14         ` Laine Stump
2013-09-25 10:56           ` Michael S. Tsirkin
2013-09-25 10:58             ` Michael S. Tsirkin
2013-09-27 17:06     ` Markus Armbruster
2013-09-28 18:12       ` Michael S. Tsirkin
2013-09-30  9:55         ` Markus Armbruster
2013-09-30 10:44           ` Laine Stump
2013-09-30 10:48           ` Michael S. Tsirkin
2013-09-30 16:01             ` Gerd Hoffmann
2013-09-30 16:06               ` Michael S. Tsirkin
2013-10-01 21:14 ` Michael S. Tsirkin

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=5242AF59.5060905@redhat.com \
    --to=laine@redhat.com \
    --cc=marcel.a@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --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).