Lines Matching +full:secure +full:- +full:reg +full:- +full:access
2 VFIO - "Virtual Function I/O" [1]_
7 allotted. This includes x86 hardware with AMD-Vi and Intel VT-d,
10 agnostic framework for exposing direct device access to userspace, in
11 a secure, IOMMU protected environment. In other words, this allows
12 safe [2]_, non-privileged, userspace drivers.
15 access ("device assignment") when configured for the highest possible
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)
28 and requires root privileges to access things like PCI configuration
33 secure, more featureful userspace driver environment than UIO.
36 ---------------------------
39 create a programming interface made up of I/O access, interrupts,
41 by far the most critical aspect for maintaining a secure environment
42 as allowing a device read-write access to system memory imposes the
49 from each other and from arbitrary memory access, thus allowing
50 things like secure direct assignment of devices into virtual machines.
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
74 ensure secure user access, it's not necessarily the preferred
96 group available, but not that particular device). TBD - interface
109 ioctls become available, enabling access to the VFIO IOMMU interfaces.
119 ------------------
121 Assume user wants to access PCI device 0000:06:0d.0::
127 pci bus, therefore the user will make use of vfio-pci to manage the
130 # modprobe vfio-pci
132 Binding this device to the vfio-pci driver creates the VFIO group
135 $ lspci -n -s 0000:06:0d.0
138 # echo 1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id
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
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
166 The user now has full access to all the devices and the iommu for this
167 group and can access them as follows::
219 struct vfio_region_info reg = { .argsz = sizeof(reg) };
221 reg.index = i;
223 ioctl(device, VFIO_DEVICE_GET_REGION_INFO, ®);
243 ----------------------------
265 Long term, VFIO users should migrate to device access through the cdev
266 interface described below, and native access through the IOMMUFD
270 ----------------
294 vfio device cdev access is still bound by IOMMU group semantics, ie. there
299 VFIO_DEVICE_BIND_IOMMUFD ioctl, which gates full device access.
302 -------------------
304 Assume user wants to access PCI device 0000:6a:01.0::
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
319 Then provide the user with access to the device if unprivileged
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 -------------------------------
481 2) The hardware supports so called DMA windows - the PCI address range
482 within which DMA transfer is allowed, any attempt to access address space
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
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 -------------------------------------------------------------------------------
678 possible for multi-function devices to have backdoors between
680 access to things like PCI config space through MMIO registers. To
682 IOMMU driver to group multi-function PCI devices together
684 still provide isolation. For PCI, SR-IOV Virtual Functions are the
688 .. [3] As always there are trade-offs to virtual machine device
691 these trade-offs.
696 -[0000:00]-+-1e.0-[06]--+-0d.0
697 \-0d.1