qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] VFIO PCIe Extended Capabilities


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] VFIO PCIe Extended Capabilities
Date: Tue, 19 Jul 2016 21:16:40 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 07/19/2016 08:55 PM, Alex Williamson wrote:
On Tue, 19 Jul 2016 11:22:29 -0600
Alex Williamson <address@hidden> wrote:

On Tue, 19 Jul 2016 17:12:45 +0000
Spenser Gilliland <address@hidden> wrote:

Hi,

I noticed your patches "vfio: add pcie extended capability support" and "vfio/pci: 
Hide SR-IOV capability" have gone into qemu mainline.  These look really good, and thanks so 
much for doing these.

I was wondering if there were any side effects to removing the 
pci_bus_is_express check on line 1776 of hw/vfio/pci.c .

     /* Only add extended caps if we have them and the guest can see them */
-   if (!pci_is_express(pdev) || !pci_bus_is_express(pdev->bus) ||
+  if (!pci_is_express(pdev) ||
         !pci_get_long(pdev->config + PCI_CONFIG_SPACE_SIZE)) {
         return 0;
     }

I'm asking because it looks like the defaults for libvirt/OpenStack are to create a 
"hostdev" stanza in the libvirt xml to define this pass through condition.  However, it 
also appears that the "hostdev" stanza only supports pci-bridge bus connections.  Thus, 
it's not easily possible to use this patch in a libvirt/OpenStack environment as the bus is 
technically a non-express bus.  It looks like adding PCIe bus support to libvirt/OpenStack may be a 
lot more effort than a simple workaround here.

I have tested this on my local system and it does work as intended for my use 
case.  The following is from an OpenStack VM and shows that the 0x340 extended 
configuration space is passed through correctly.  I've also done testing which 
uses this space and the results are positive.

If the bus is not express then extended capabilities on the device
should not be accessible, this would be a QEMU bug for allowing it.
Cc'ing Marcel for that.  Thanks,

Hi Spencer,

Indeed, if a device is attached to a PCI bus it makes no sense to advertise the 
extended configuration space.
Can you please share the QEMU command line? Maybe is possible to make the 
device's bus PCIe in QEMU?


In fact, I've tried to fix this multiple times:

https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05384.html
https://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg02422.html
https://lists.nongnu.org/archive/html/qemu-devel/2016-01/msg03259.html

Yet the patch remains unapplied :(

I thought is it in already. Maybe Michael can add it as part of the hard freeze.
And if the patch will be applied, the tweak above wouldn't help, right Alex?

Thanks,
Marcel






reply via email to

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