K 10
svn:author
V 4
ngie
K 8
svn:date
V 27
2016-01-03T05:39:19.846581Z
K 7
svn:log
V 2743
MFC r279447,r279449,r279450,r279451,r279452,r279453:

r279447 (by rstone):

Implement interface to create SR-IOV Virtual Functions

Implement the interace to create SR-IOV Virtual Functions (VFs).
When a driver registers that they support SR-IOV by calling
pci_setup_iov(), the SR-IOV code creates a new node in /dev/iov
for that device.  An ioctl can be invoked on that device to
create VFs and have the driver initialize them.

At this point, allocating memory I/O windows (BARs) is not
supported.

r279449 (by rstone):

Allocate PCI I/O memory spaces for VFs

When creating VFs, we must size each SR-IOV BAR on the PF and
allocate a configuous I/O memory window large enough for every VF.
However, the window only needs to be aligned to a boundary equal
to the size of the window for a single VF.

When a VF attempts to allocate an I/O memory resource, we must
intercept the request in the pci driver and pass it off to the
SR-IOV code, which will allocate the correct window from the
pre-allocated memory space for the PF.

Inform the pci driver about the size and address of the BARs on
the VF when the VF is created.  This is required by pciconf -b and
bhyve.

r279450 (by rstone):

Add interface to destroy SR-IOV VFs

r279451 (by rstone):

Add infrastructure for exporting config schema from PF drivers

r279452 (by rstone):

Add function to validate the consistency of SR-IOV config

Add a function that validates that the user-provided SR-IOV
configuration is valid.  This includes basic checks that the
structure of the configuration is correct (e.g. all required
configuration nodes are present) as well as validating against
a configuration schema.

The schema validation consists of:
 - Ensuring that all required config parameters are present.
 - If the schema defines a default value for a parameter,
   adding the default value if the parameter is not set.
 - Ensuring that no parameters are specified in the config
   that are not defined in the schema.
 - Ensuring that have the correct type defined in the schema.
 - Ensuring that no configuration nodes are present for devices
   that do not exist.  For example, if 2 VFs are configured,
   then we validate that a node called VF-5 does not exist.

r279453 (by rstone):

Pass SR-IOV configuration to kernel using an nvlist

Pass all SR-IOV configuration to the kernel using an nvlist.  The
main benefit that this offers is flexibility.  It allows a driver
to accept any number of parameters of any type supported by the
SR-IOV configuration infrastructure with having to make any
changes outside of the driver.

It also offers the user very fine-grained control over the
configuration of the VFs -- if they want, they can have different
configuration applied to every VF.

END