On Wed, Sep 25, 2013 at 11:48:28AM +0300, 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.
Heh PCI-SIG keeps fighting against legacy interrupts and IO.
But lots of hardware happily ignores these rules.
And the reason is simple: software does not enforce them.
Here's integrated stuff on my laptop:
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00
[VGA controller])
Subsystem: Lenovo Device 21cf
Flags: bus master, fast devsel, latency 0, IRQ 43
Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 5000 [size=64]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
So it has an IO BAR.
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI])
Subsystem: Lenovo Device 21cf
Flags: bus master, medium devsel, latency 0, IRQ 16
Memory at f252a000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
Kernel driver in use: ehci-pci
So IRQ but no MSI.
> I suppose that this restriction can be removed for PCI devices that
> 1. Actually work when plugged in into RC Integrated EndPoint
> 2. Respond to the above limitations
These limitations are just guidance for future devices.
They can't change the past, such devices were made.
> >
> > > and had planned to
> > > prevent attaching them to PCIe root ports (ioh3420 device) and PCIe
> > > downstream switch ports (xio-3130 device) as well. I did this because,
> > > even though qemu currently allows attaching a normal PCI device in any
> > > of these three places, the restriction exists for real hardware and I
> > > didn't see any guarantee that qemu wouldn't add the restriction in the
> > > future in order to more closely emulate real hardware.
> > >
> > > However, since I did that, I've learned that many of the qemu "pci"
> > > devices really should be considered as "pci or pcie". Gerd Hoffman lists
> > > some of these cases in a bug he filed against libvirt:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1003983
> > >
> > > I would like to loosen up the restrictions in libvirt, but want to make
> > > sure that I don't allow something that could later be forbidden by qemu
> > > (thus creating a compatibility problem during upgrades). Beyond Gerd's
> > > specific requests to allow ehci, uhci, and hda controllers to attach to
> > > PCIe ports, are there any other devices that I specifically should or
> > > shouldn't allow? (I would rather be conservative in what I allow - it's
> > > easy to allow more things later, but nearly impossible to revoke
> > > permission once it's been allowed).
> For the moment I would not remove any restrictions, but only the ones
> requested and verified by somebody.
>
> >
> > 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
> 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
>
> Any thoughts?
> Thanks,
> Marcel
It's all not too hard to implement, we just need to know
what kind of interface makes sense for management.
So Cc libvir-list@xxxxxxxxxx .
>
> >
>
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list