summaryrefslogtreecommitdiff
path: root/Documentation/vfio.txt
diff options
context:
space:
mode:
authorAlex Williamson <alex.williamson@redhat.com>2013-09-04 11:28:04 -0600
committerAlex Williamson <alex.williamson@redhat.com>2013-09-04 11:28:04 -0600
commit8b27ee60bfd6bbb84d2df28fa706c5c5081066ca (patch)
tree1fab334bc5bfdc157df746cda06ad328cc1a5208 /Documentation/vfio.txt
parent3bc4f3993b93dbf1f6402e2034a2e20eb07db807 (diff)
vfio-pci: PCI hot reset interface
The current VFIO_DEVICE_RESET interface only maps to PCI use cases where we can isolate the reset to the individual PCI function. This means the device must support FLR (PCIe or AF), PM reset on D3hot->D0 transition, device specific reset, or be a singleton device on a bus for a secondary bus reset. FLR does not have widespread support, PM reset is not very reliable, and bus topology is dictated by the system and device design. We need to provide a means for a user to induce a bus reset in cases where the existing mechanisms are not available or not reliable. This device specific extension to VFIO provides the user with this ability. Two new ioctls are introduced: - VFIO_DEVICE_PCI_GET_HOT_RESET_INFO - VFIO_DEVICE_PCI_HOT_RESET The first provides the user with information about the extent of devices affected by a hot reset. This is essentially a list of devices and the IOMMU groups they belong to. The user may then initiate a hot reset by calling the second ioctl. We must be careful that the user has ownership of all the affected devices found via the first ioctl, so the second ioctl takes a list of file descriptors for the VFIO groups affected by the reset. Each group must have IOMMU protection established for the ioctl to succeed. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Diffstat (limited to 'Documentation/vfio.txt')
0 files changed, 0 insertions, 0 deletions