Lines Matching +full:group +full:- +full:index +full:- +full:bits
2 VFIO - "Virtual Function I/O" [1]_
7 allotted. This includes x86 hardware with AMD-Vi and Intel VT-d,
12 safe [2]_, non-privileged, userspace drivers.
19 bare-metal device drivers [3]_.
22 field, also benefit from low-overhead, direct device access from
23 userspace. Examples include network adapters (often non-TCP/IP based)
36 ---------------------------
42 as allowing a device read-write access to system memory imposes the
55 For instance, an individual device may be part of a larger multi-
59 could be anything from a multi-function PCI device with backdoors
60 between functions to a non-PCI-ACS (Access Control Services) capable
62 can also play a factor in terms of hiding devices. A PCIe-to-PCI
69 IOMMU API therefore supports a notion of IOMMU groups. A group is
73 While the group is the minimum granularity that must be used to
85 The user needs to add a group into the container for the next level
87 group associated with the desired device. This can be done using
90 VFIO group will appear for the group as /dev/vfio/$GROUP, where
91 $GROUP is the IOMMU group number of which the device is a member.
92 If the IOMMU group contains multiple devices, each will need to
93 be bound to a VFIO driver before operations on the VFIO group
96 group available, but not that particular device). TBD - interface
99 Once the group is ready, it may be added to the container by opening
100 the VFIO group character device (/dev/vfio/$GROUP) and using the
104 be set to the same container. If a group fails to set to a container
108 With a group (or groups) attached to a container, the remaining
111 device within a group using an ioctl on the VFIO group file descriptor.
119 ------------------
126 This device is therefore in IOMMU group 26. This device is on the
127 pci bus, therefore the user will make use of vfio-pci to manage the
128 group::
130 # modprobe vfio-pci
132 Binding this device to the vfio-pci driver creates the VFIO group
133 character devices for this group::
135 $ lspci -n -s 0000:06:0d.0
138 # echo 1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id
140 Now we need to look at what other devices are in the group to free
143 $ ls -l /sys/bus/pci/devices/0000:06:0d.0/iommu_group/devices
145 lrwxrwxrwx. 1 root root 0 Apr 23 16:13 0000:00:1e.0 ->
147 lrwxrwxrwx. 1 root root 0 Apr 23 16:13 0000:06:0d.0 ->
149 lrwxrwxrwx. 1 root root 0 Apr 23 16:13 0000:06:0d.1 ->
152 This device is behind a PCIe-to-PCI bridge [4]_, therefore we also
153 need to add device 0000:06:0d.1 to the group following the same
156 bind this device to the vfio-pci driver (vfio-pci does not currently
159 The final step is to provide the user with access to the group if
167 group and can access them as follows::
169 int container, group, device, i;
185 /* Open the group */
186 group = open("/dev/vfio/26", O_RDWR);
188 /* Test the group is viable and available */
189 ioctl(group, VFIO_GROUP_GET_STATUS, &group_status);
192 /* Group is not viable (ie, not all devices bound for vfio) */
194 /* Add the group to the container */
195 ioctl(group, VFIO_GROUP_SET_CONTAINER, &container);
213 device = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, "0000:06:0d.0");
221 reg.index = i;
232 irq.index = i;
243 ----------------------------
250 vfio container and group model is intended to be deprecated.
270 ----------------
273 in a VFIO group.
279 the legacy group interface if noiommu is wanted.
287 VFIO device cdev doesn't rely on VFIO group/container/iommu drivers.
294 vfio device cdev access is still bound by IOMMU group semantics, ie. there
295 can be only one DMA owner for the group. Devices belonging to the same
296 group can not be bound to multiple iommufd_ctx or shared between native
302 -------------------
306 $ ls /sys/bus/pci/devices/0000:6a:01.0/vfio-dev/
312 $ ls -l /dev/vfio/devices/vfio0
313 crw------- 1 root root 511, 0 Feb 16 01:22 /dev/vfio/devices/vfio0
314 $ cat /sys/bus/pci/devices/0000:6a:01.0/vfio-dev/vfio0/dev
316 $ ls -l /dev/char/511\:0
317 lrwxrwxrwx 1 root root 21 Feb 16 01:22 /dev/char/511:0 -> ../vfio/devices/vfio0
374 -------------------------------------------------------------------------------
379 -------------------------------------------------------------------------------
381 VFIO bus drivers, such as vfio-pci make use of only a few interfaces
437 - The init/release callbacks are issued when vfio_device is initialized
440 - The open/close device callbacks are issued when the first
444 - The ioctl callback provides a direct pass through for some VFIO_DEVICE_*
447 - The [un]bind_iommufd callbacks are issued when the device is bound to
450 - The [de]attach_ioas callback is issued when the device is attached to
455 - The read/write/mmap callbacks implement the device region access defined
458 - The request callback is issued when device is going to be unregistered,
461 - The dma_unmap callback is issued when a range of iovas are unmapped
468 -------------------------------
472 1) On older systems (POWER7 with P5IOC2/IODA1) only one IOMMU group per
474 one table per a IOMMU group which is a Partitionable Endpoint (PE)
481 2) The hardware supports so called DMA windows - the PCI address range
494 error recovery. A PE may be a single or multi-function IOA (IO Adapter), a
495 function of a multi-function IOA, or multiple IOAs (possibly including
521 /* Add the group to the container */
522 ioctl(group, VFIO_GROUP_SET_CONTAINER, &container);
546 device = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, "0000:06:0d.0");
561 * PE, and put child devices belonging to same IOMMU group to the
575 /* Inject EEH error, which is expected to be caused by 32-bits
639 - VFIO_IOMMU_SPAPR_REGISTER_MEMORY/VFIO_IOMMU_SPAPR_UNREGISTER_MEMORY ioctls
646 - VFIO_IOMMU_MAP_DMA/VFIO_IOMMU_UNMAP_DMA ioctls only update the actual
648 address is from pre-registered range.
658 be as big as entire RAM, use different page size, it is optional - guests
659 create those in run-time if the guest driver supports 64bit DMA.
671 -------------------------------------------------------------------------------
674 -------------------------------
677 control to the hypervisor and para-virtualize the IOMMU interface for
690 - Documentation/virt/kvm/devices/vfio.rst
691 - Documentation/virt/kvm/arm/pviommu.rst
694 -------------------------------------------------------------------------------
701 possible for multi-function devices to have backdoors between
705 IOMMU driver to group multi-function PCI devices together
707 still provide isolation. For PCI, SR-IOV Virtual Functions are the
711 .. [3] As always there are trade-offs to virtual machine device
714 these trade-offs.
719 -[0000:00]-+-1e.0-[06]--+-0d.0
720 \-0d.1