Date:	Mon, 01 Feb 2016 17:24:00 -0700
From:	Alex Williamson <alex.williamson@...hat.com>
To:	alex.williamson@...hat.com
Cc:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	kraxel@...hat.com
Subject: [PATCH 0/8] vfio: capability chains, sparse mmaps,
 device specific regions, IGD OpRegions

We have a number of cases were we want to extend the vfio API to
provide further details in the vfio INFO ioctls.  For instance we take
it as implicit that we can't mmap over MSI-X vector tables of a BAR,
but we'd prefer to have the API define that explicitly as a sparse
mmap capable region.  We have some devices that need additional
regions, but we don't want to "burn" a region index for something
specific to a single device.  We also have the ongoing problem of
describing valid IOVA ranges for an IOMMU.  This series doesn't solve
every case of those problems, but it solves some and gives us the vfio
level API to solve the others.

To do this we use capability chains, much like they're used in PCI.
A flag bit in the INFO ioctl structure tells us whether a capability
chain is present and new fields are defined to provide the buffer
index of the first capability.  Each capability provides the start
index of the next capability along with an identifier and version of
itself.  The existing argsz field of is used to convey to the user the
necessary buffer size to retrieve all of the capabilities.  A few
helpers in the vfio core simplifies the mechanics of adding
capabilities for the bus and iommu drivers to make use of.

The sparse mmap capability solves the problem of regions which can
only be partially mmaped, such as when an MSI-X table is present.
This is also expected to be useful for vGPU support should a device
have a mix of direct access and emulated access within the same
region.

The device specific region capability allows us to easily add new
regions that are device specific.  Included here is the IGD OpRegion,
which is a host memory region exclusively for the configuration and
use of Intel graphics devices, but is not part of the device in the
PCI sense.  There are potentially other regions we can expose on this
device to further facilitate use of it.

I particularly welcome feedback on how we identify device specific
regions.  Here I've used a type and sub-type field where I've defined
one bit of the type field to identify a vendor specific type with a
mask to identify the vendor.  In the Opregion case here, that defines
an 8086 set of sub-types where I've simply defined sub-type 1 as an
IGD OpRegion.  We could of course get the vendor from the device
itself, but this method might promote code re-use if we eventually
have multiple vendors using regions for the same purpose.  At least
that's my thinking.

Appreciate feedback.  Thanks,

Alex

---

Alex Williamson (8):
      vfio: Define capability chains
      vfio: Add capability chain helpers
      vfio: Define sparse mmap capability for regions
      vfio/pci: Include sparse mmap capability for MSI-X table regions
      vfio: Define device specific region type capability
      vfio/pci: Add infrastructure for additional device specific regions
      vfio/pci: Enable virtual register in PCI config space
      vfio/pci: Intel IGD OpRegion support


 drivers/vfio/pci/Kconfig            |    4 +
 drivers/vfio/pci/Makefile           |    1 
 drivers/vfio/pci/vfio_pci.c         |  159 ++++++++++++++++++++++++++++++++++-
 drivers/vfio/pci/vfio_pci_config.c  |   34 +++++++
 drivers/vfio/pci/vfio_pci_igd.c     |  117 ++++++++++++++++++++++++++
 drivers/vfio/pci/vfio_pci_private.h |   39 +++++++++
 drivers/vfio/vfio.c                 |   54 ++++++++++++
 include/linux/vfio.h                |   11 ++
 include/uapi/linux/vfio.h           |   89 +++++++++++++++++++-
 9 files changed, 497 insertions(+), 11 deletions(-)
 create mode 100644 drivers/vfio/pci/vfio_pci_igd.c

Powered by blists - more mailing lists