All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Spenser Gilliland <spenser.gilliland@xilinx.com>
Cc: "chen.fan.fnst@cn.fujitsu.com" <chen.fan.fnst@cn.fujitsu.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Marcel Apfelbaum <marcel@redhat.com>
Subject: Re: [Qemu-devel] VFIO PCIe Extended Capabilities
Date: Tue, 19 Jul 2016 11:22:29 -0600	[thread overview]
Message-ID: <20160719112229.409eee63@t450s.home> (raw)
In-Reply-To: <66583216254AFC43ADCD7BD88016E00698544F11@XSJ-PSEXMBX02.xlnx.xilinx.com>

On Tue, 19 Jul 2016 17:12:45 +0000
Spenser Gilliland <spenser.gilliland@xilinx.com> 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	other threads:[~2016-07-19 17:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19 17:12 [Qemu-devel] VFIO PCIe Extended Capabilities Spenser Gilliland
2016-07-19 17:22 ` Alex Williamson [this message]
2016-07-19 17:55   ` Alex Williamson
2016-07-19 18:16     ` Marcel Apfelbaum
2016-07-19 18:30       ` Alex Williamson
2016-07-19 19:03         ` Marcel Apfelbaum
2016-07-19 20:39           ` Spenser Gilliland
2016-07-19 20:51             ` Alex Williamson
2016-07-19 21:25               ` Spenser Gilliland

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=20160719112229.409eee63@t450s.home \
    --to=alex.williamson@redhat.com \
    --cc=chen.fan.fnst@cn.fujitsu.com \
    --cc=marcel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=spenser.gilliland@xilinx.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.