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: Alex Williamson
Subject: Re: [Qemu-devel] VFIO PCIe Extended Capabilities
Date: Tue, 19 Jul 2016 11:22:29 -0600

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,

Alex



reply via email to

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