Lines Matching full:the
9 * it under the terms of the GNU General Public License version 2 as
10 * published by the Free Software Foundation.
43 * The No-IOMMU IOMMU offers no translation or isolation for devices and
45 * code will taint the host kernel and should be used with extreme caution.
53 * Supports the vaddr flag for DMA map and unmap. Not supported for mediated
60 * The IOCTL interface is designed for extensibility by embedding the
62 * kernel and userspace. We therefore use the _IO() macro for these
63 * defines to avoid implicitly embedding a size into the ioctl request.
66 * It's *always* the caller's responsibility to indicate the size of
67 * the structure passed by setting argsz appropriately.
76 * this capability chain is supported and a field defined in the fixed
77 * structure defines the offset of the first capability in the chain.
78 * This field is only valid when the corresponding bit in the flags
79 * bitmap is set. This offset field is relative to the start of the
80 * INFO buffer, as is the next field within each capability header.
81 * The id within the header is a shared address space per INFO ioctl,
82 * while the version field is specific to the capability id. The
83 * contents following the header are specific to the capability id.
87 __u16 version; /* Version specific to the capability ID */
93 * the capability chain flag bit set, a zero value for the first capability
94 * offset (if available within the provided argsz), and argsz will be
95 * updated to report the necessary buffer size. For compatibility, the
96 * INFO ioctl will not report error in this case, but the capability chain
105 * Report the version of the VFIO API. This allows us to bump the entire
125 * Set the iommu to the given type. The type must be supported by an
126 * iommu driver as verified by calling CHECK_EXTENSION using the same
128 * ioctl is available. The IOMMU interfaces enabled by this call are
129 * specific to the value set.
141 * Retrieve information about the group. Fills in provided
157 * Set the container for the VFIO group to the open VFIO file
160 * groups. Only when a container is set are all of the interfaces
161 * of the VFIO file descriptor and the VFIO group file descriptor
162 * available to the user.
171 * Remove the group from the attached container. This is the
172 * opposite of the SET_CONTAINER call and returns the group to
174 * prior to calling this interface. When removing the last group
175 * from a container, the IOMMU will be disabled and all state lost,
176 * effectively also returning the VFIO file descriptor to an initial
186 * Return a new file descriptor for the device object described by
187 * the provided string. The string should match a device listed in
188 * the devices subdirectory of the IOMMU group sysfs entry. The
189 * group containing the device must already be added to this context.
201 * Retrieve information about the device. Fills in provided
227 * of the following corresponding to device flags in vfio_device_info structure.
237 * The following capabilities are unique to s390 zPCI devices. Their contents
246 * The following VFIO_DEVICE_INFO capability reports support for PCIe AtomicOp
247 * completion to the root bus with supported widths provided via flags.
286 * The sparse mmap capability allows finer granularity of specifying areas
287 * within a region with mmap support. When specified, the user should only
288 * mmap the offset ranges specified by the areas array. mmaps outside of the
289 * areas specified may fail (such as the range covering a PCI MSI-X table) or
292 * The structures below define version 1 of this capability.
309 * The device specific type capability allows regions unique to a specific
310 * device or class of devices to be exposed. This helps solve the problem for
312 * on the device, without needing to resort to static indexes, as done by
316 * make a "VGA" device specific type to describe the VGA access space. This
317 * means that non-VGA devices wouldn't need to waste this index, and thus the
321 * The current implementation is now part of the user ABI, so we can't use this
326 * The structure below defines version 1 of this capability.
357 * NVIDIA GPU NVlink2 RAM is coherent RAM mapped onto the host address space.
380 * The EDID blob has monitor information such as brand, name, serial
384 * EDID for the virtual monitor, which allows a flexible display
387 * For the edid blob spec look here:
390 * On linux systems you can find the EDID blob in sysfs:
393 * You can use the edid-decode ulility (comes with xorg-x11-utils) to
394 * decode the EDID blob.
396 * @edid_offset: location of the edid blob, relative to the
397 * start of the region (readonly).
398 * @edid_max_size: max size of the edid blob (readonly).
459 * The MSIX mappable capability informs that MSIX data of a BAR can be mmapped
461 * the same system page.
463 * Even though the userspace gets direct access to the MSIX data, the existing
471 * and by the userspace to associate a NVLink bridge with a GPU.
483 * Capability with an NVLink link speed. The value is read by
484 * the NVlink2 bridge driver from the bridge's "ibm,nvlink-speed"
485 * property in the device tree. The value is fixed in the hardware
486 * and failing to provide the correct value results in the link
487 * not working with no indication from the driver why.
510 * The EVENTFD flag indicates the interrupt index supports eventfd based
513 * The MASKABLE flags indicates the index supports MASK and UNMASK
516 * AUTOMASKED indicates that after signaling, the interrupt line is
517 * automatically masked by VFIO and the user needs to unmask the line
521 * The NORESIZE flag indicates that the interrupt lines within the index
523 * disabling the entire index. This is used for interrupts like PCI MSI
524 * and MSI-X where the driver may only use a subset of the available
526 * upfront. In the case of MSI-X, where the user can enable MSI-X and
527 * then add and unmask vectors, it's up to userspace to make the decision
528 * whether to allocate the maximum supported number of vectors or tear
529 * down setup and incrementally increase the vectors as each is enabled.
530 * Absence of the NORESIZE flag indicates that vectors can be enabled
531 * and disabled dynamically without impacting other vectors within the
551 * the range of subindexes being specified.
553 * The DATA flags specify the type of data provided. If DATA_NONE, the
554 * operation performs the specified action immediately on the specified
558 * DATA_BOOL allows sparse support for the same on arrays of interrupts.
563 * DATA_EVENTFD binds the specified ACTION to the provided __s32 eventfd.
577 * enables the interrupt index for the device. Individual subindex interrupts
578 * can be disabled using the -1 value for DATA_EVENTFD or the index can be
614 * The VFIO-PCI bus driver makes use of the following fixed region and
631 * as well as the MMIO range 0xa0000 to 0xbffff. Each implemented
632 * range is found at it's identity mapped offset from the region
651 * The vfio-ccw bus driver makes use of the following fixed region and
669 * The vfio-ap bus driver makes use of the following IRQ index mapping.
682 * This command is used to query the affected devices in the hot reset for
685 * This command always reports the segment, bus, and devfn information for
686 * each affected device, and selectively reports the group_id or devid per
687 * the way how the calling device is opened.
689 * - If the calling device is opened via the traditional group/container
691 * the affected devices and provides a set of group fds to prove the
694 * - If the calling device is opened as a cdev, devid is reported.
696 * data type. All the affected devices should be represented in
697 * the dev_set, ex. bound to a vfio driver, and also be owned by
698 * this interface which is determined by the following conditions:
699 * 1) Has a valid devid within the iommufd_ctx of the calling device.
701 * the cdev calling conventions do not support a proof-of-ownership
702 * model as provided in the legacy group interface. In this case
703 * valid devid with value greater than zero is provided in the return
705 * 2) Does not have a valid devid within the iommufd_ctx of the calling
706 * device, but belongs to the same IOMMU group as the calling device
707 * or another opened device that has a valid devid within the
708 * iommufd_ctx of the calling device. This provides implicit ownership
709 * for devices within the same DMA isolation context. In this case
710 * the devid value of VFIO_PCI_DEVID_OWNED is provided in the return
713 * A devid value of VFIO_PCI_DEVID_NOT_OWNED is provided in the return
714 * structure for affected devices where device is NOT represented in the
715 * dev_set or ownership is not available. Such devices prevent the use
716 * of VFIO_DEVICE_PCI_HOT_RESET ioctl outside of the proof-of-ownership
718 * VFIO_PCI_HOT_RESET_FLAG_DEV_ID_OWNED would be set when all the
719 * affected devices are represented in the dev_set and also owned by
720 * the user. This flag is available only when
723 * length fd array on the calling device as the ownership is validated
757 * other devices sharing the bus/slot. The calling user must have
758 * ownership of the full set of affected devices as determined by the
761 * When called on a device file descriptor acquired through the vfio
762 * group interface, the user is required to provide proof of ownership
763 * of those affected devices via the group_fds array in struct
766 * When called on a direct cdev opened vfio device, the flags field of
767 * struct vfio_pci_hot_reset_info reports the ownership status of the
771 * Mixed usage of legacy groups and cdevs across the set of affected
789 * Set the drm_plane_type and flags, then retrieve the gfx plane info.
793 * to ask if the mdev supports dma-buf. 0 on support, -EINVAL on no
796 * to ask if the mdev supports region. 0 on support, -EINVAL on no
799 * with each call to query the plane info.
842 * described by the provided dmabuf_id. The dmabuf_id is returned from VFIO_
843 * DEVICE_QUERY_GFX_PLANE as a token of the exposed guest framebuffer.
852 * Perform a write to the device at the specified device fd offset, with
853 * the specified data and width when the provided eventfd is triggered.
856 * excluding the MSI-X vector table.
880 * Get, set, or probe feature data of the device. The feature is selected
881 * using the FEATURE_MASK portion of the flags field. Support for a feature
882 * can be probed by setting both the FEATURE_MASK and PROBE bits. A probe
883 * may optionally include the GET and/or SET bits to determine read vs write
884 * access of the feature respectively. Probing a feature will return success
885 * if the feature is supported and all of the optionally indicated GET/SET
886 * methods are supported. The format of the data portion of the structure is
887 * specific to the given feature. The data portion is not required for
910 * @out_devid: The device id generated by this bind. devid is a handle for
913 * Bind a vfio_device to the specified iommufd.
915 * User is restricted from accessing the device before the binding operation
936 * @pt_id: Input the target id which can represent an ioas or a hwpt
938 * Output the input ioas id or the attached hwpt id which could
939 * be the specified hwpt itself or a hwpt automatically created
940 * for the specified ioas by kernel during the attachment.
941 * @pasid: The pasid to be attached, only meaningful when
944 * Associate the device with an address space within the bound iommufd.
951 * This action, also known as a hw_pagetable replacement, will replace the
952 * currently attached hwpt of the device or the pasid of this device with a new
953 * hwpt corresponding to the given pt_id.
972 * @pasid: The pasid to be detached, only meaningful when
975 * Remove the association of the device or a pasid of the device and its current
976 * associated address space. After it, the device or the pasid should be in a
993 * PCI SR-IOV PF when SR-IOV is enabled on the PF and there are no existing
1000 * Indicates the device can support the migration API through
1001 * VFIO_DEVICE_FEATURE_MIG_DEVICE_STATE. If this GET succeeds, the RUNNING and
1003 * indicated via the flags field; at least VFIO_MIGRATION_STOP_COPY must be
1010 * is supported in addition to the STOP_COPY states.
1013 * PRE_COPY is supported in addition to the STOP_COPY states.
1017 * in addition to the STOP_COPY states.
1019 * Other combinations of flags have behavior to be defined in the future.
1030 * Upon VFIO_DEVICE_FEATURE_SET, execute a migration state change on the VFIO
1031 * device. The new state is supplied in device_state, see enum
1034 * The kernel migration driver must fully transition the device to the new state
1035 * value before the operation returns to the user.
1037 * The kernel migration driver must not generate asynchronous device state
1038 * transitions outside of manipulation by the user or the VFIO_DEVICE_RESET
1041 * If this function fails then current device_state may be the original
1042 * operating state or some other state along the combination transition path.
1043 * The user can then decide if it should execute a VFIO_DEVICE_RESET, attempt
1044 * to return to the original state, or attempt to return to some other state
1047 * If the new_state starts a new data transfer session then the FD associated
1048 * with that session is returned in data_fd. The user is responsible to close
1049 * this FD when it is finished. The user must consider the migration data stream
1050 * carried over the FD to be opaque and must preserve the byte order of the
1051 * stream. The user is not required to preserve buffer segmentation when writing
1052 * the data stream during the RESUMING operation.
1054 * Upon VFIO_DEVICE_FEATURE_GET, get the current migration state of the VFIO
1064 * The device migration Finite State Machine is described by the enum
1065 * vfio_device_mig_state. Some of the FSM arcs will create a migration data
1066 * transfer session by returning a FD, in this case the migration data will
1067 * flow over the FD using read() and write() as discussed below.
1070 * RUNNING - The device is running normally
1071 * STOP - The device does not change the internal or external state
1072 * STOP_COPY - The device internal state can be read out
1073 * RESUMING - The device is stopped and is loading a new internal state
1074 * ERROR - The device has failed and must be reset
1077 * RUNNING_P2P - RUNNING, except the device cannot do peer to peer DMA
1079 * PRE_COPY - The device is running normally but tracking internal state
1082 * PRE_COPY_P2P - PRE_COPY, except the device cannot do peer to peer DMA
1084 * The FSM takes actions on the arcs between FSM states. The driver implements
1085 * the following behavior for the FSM arcs:
1089 * While in STOP the device must stop the operation of the device. The device
1091 * It must not change its internal state. When stopped the device and kernel
1093 * subsystems in the STOP state, for example PCI MSI-X and PCI config space.
1094 * Failure by the user to restrict device access while in STOP must not result
1095 * in error conditions outside the user context (ex. host system faults).
1097 * The STOP_COPY arc will terminate a data transfer session.
1100 * Leaving RESUMING terminates a data transfer session and indicates the
1101 * device should complete processing of the data delivered by write(). The
1102 * kernel migration driver should complete the incorporation of data written
1103 * to the data transfer FD into the device internal state and perform
1104 * final validity and consistency checking of the new device state. If the
1106 * invalid, the migration driver must fail the SET_STATE ioctl and
1107 * optionally go to the ERROR state as described below.
1109 * While in STOP the device has the same behavior as other STOP states
1112 * To abort a RESUMING session the device must be reset.
1116 * While in RUNNING the device is fully operational, the device may generate
1118 * and the device may advance its internal state.
1120 * The PRE_COPY arc will terminate a data transfer session.
1125 * While in RUNNING_P2P the device is partially running in the P2P quiescent
1128 * The PRE_COPY_P2P arc will terminate a data transfer session.
1133 * PRE_COPY, PRE_COPY_P2P and STOP_COPY form the "saving group" of states
1136 * the associated fd.
1138 * These arcs begin the process of saving the device state and will return a
1139 * new data_fd. The migration driver may perform actions such as enabling
1142 * Each arc does not change the device operation, the device remains
1143 * RUNNING, P2P quiesced or in STOP. The STOP_COPY state is described below
1147 * Entering PRE_COPY_P2P continues all the behaviors of PRE_COPY above.
1148 * However, while in the PRE_COPY_P2P state, the device is partially running
1149 * in the P2P quiescent state defined below, like RUNNING_P2P.
1152 * This arc allows returning the device to a full RUNNING behavior while
1153 * continuing all the behaviors of PRE_COPY.
1156 * While in the STOP_COPY state the device has the same behavior as STOP
1157 * with the addition that the data transfers session continues to stream the
1158 * migration state. End of stream on the FD indicates the entire device
1161 * The user should take steps to restrict access to vfio device regions while
1162 * the device is in STOP_COPY or risk corruption of the device migration data
1166 * Entering the RESUMING state starts a process of restoring the device state
1167 * and will return a new data_fd. The data stream fed into the data_fd should
1168 * be taken from the data transfer output of a single FD during saving from
1169 * a compatible device. The migration driver may alter/reset the internal
1170 * device state for this arc if required to prepare the device to receive the
1182 * can be failed with an errno return and may then move the device_state into
1183 * ERROR. In this case the device was unable to execute the requested arc and
1184 * was also unable to restore the device to any valid device_state.
1185 * To recover from ERROR VFIO_DEVICE_RESET must be used to return the
1188 * The optional peer to peer (P2P) quiescent state is intended to be a quiescent
1189 * state for the device for the purposes of managing multiple devices within a
1190 * user context where peer-to-peer DMA between devices may be active. The
1191 * RUNNING_P2P and PRE_COPY_P2P states must prevent the device from initiating
1192 * any new P2P DMA transactions. If the device can identify P2P transactions
1193 * then it can stop only P2P DMA, otherwise it must stop all DMA. The migration
1194 * driver must complete any such outstanding operations prior to completing the
1195 * FSM arc into a P2P state. For the purpose of specification the states
1196 * behave as though the device was fully running if not supported. Like while in
1197 * STOP or STOP_COPY the user must not touch the device, otherwise the state
1200 * The remaining possible transitions are interpreted as combinations of the
1201 * above FSM arcs. As there are multiple paths through the FSM arcs the path
1202 * should be selected based on the following rules:
1203 * - Select the shortest path.
1204 * - The path cannot have saving group states as interior arcs, only
1206 * Refer to vfio_mig_get_next_state() for the result of the algorithm.
1208 * The automatic transit through the FSM arcs that make up the combination
1209 * transition is invisible to the user. When working with combination arcs the
1210 * user may see any step along the path in the device_state if SET_STATE
1215 * The optional states cannot be used with SET_STATE if the device does not
1216 * support them. The user can discover if these states are supported by using
1217 * VFIO_DEVICE_FEATURE_MIGRATION. By using combination transitions the user can
1218 * avoid knowing about these optional states if the kernel driver supports them.
1238 * This ioctl is used on the migration data FD in the precopy phase of the
1239 * migration data transfer. It returns an estimate of the current data sizes
1240 * remaining to be transferred. It allows the user to judge when it is
1246 * The vfio_precopy_info data structure returned by this ioctl provides
1247 * estimates of data available from the device during the PRE_COPY states.
1251 * The initial_bytes field indicates the amount of initial precopy
1252 * data available from the device. This field should have a non-zero initial
1253 * value and decrease as migration data is read from the device.
1257 * The dirty_bytes field tracks device state changes relative to data
1259 * the internal device state is modified or decrease as that modified
1260 * state is read from the device.
1262 * Userspace may use the combination of these fields to estimate the
1263 * potential data size available during the PRE_COPY phases, as well as
1264 * trends relative to the rate the device is dirtying its internal
1266 * to the data size available during the STOP_COPY phase.
1268 * Drivers have a lot of flexibility in when and what they transfer during the
1271 * During pre-copy the migration data FD has a temporary "end of stream" that is
1273 * may indicate that the device is idle and not currently dirtying any internal
1274 * state. When read() is done on this temporary end of stream the kernel driver
1278 * Once in STOP_COPY the migration data FD has a permanent end of stream
1279 * signaled in the usual way by read() always returning 0 and poll always
1296 * Upon VFIO_DEVICE_FEATURE_SET, allow the device to be moved into a low power
1297 * state with the platform-based power management. Device use of lower power
1298 * states depends on factors managed by the runtime power management core,
1301 * usage by the device, nor is a mechanism provided through this feature to
1302 * know the current power state of the device. If any device access happens
1303 * (either from the host or through the vfio uAPI) when the device is in the
1304 * low power state, then the host will move the device out of the low power
1305 * state as necessary prior to the access. Once the access is completed, the
1306 * device may re-enter the low power state. For single shot low power support
1315 * This device feature has the same behavior as
1316 * VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY with the exception that the user
1317 * provides an eventfd for wake-up notification. When the device moves out of
1318 * the low power state for the wake-up, the host will not allow the device to
1319 * re-enter a low power state without a subsequent user call to one of the low
1321 * disabled on LOW_POWER_ENTRY_WITH_WAKEUP and may only be resumed after the
1322 * low power exit. The low power exit can happen either through LOW_POWER_EXIT
1323 * or through any other access (where the wake-up notification has been
1324 * generated). The access to mmap'd device regions will not trigger low power
1327 * The notification through the provided eventfd will be generated only when
1328 * the device has entered and is resumed from a low power state after
1330 * state, as managed through the runtime power management core, will not
1331 * generate a notification through the provided eventfd on access. Calling the
1332 * LOW_POWER_EXIT feature is optional in the case where notification has been
1333 * signaled on the provided eventfd that a resume from low power has occurred.
1347 * in the latter case if the device had previously entered a low power state.
1353 * VFIO_DEVICE_FEATURE_PROBE can be used to detect if the device supports
1356 * DMA logging allows a device to internally record what DMAs the device is
1357 * initiating and report them back to userspace. It is part of the VFIO
1359 * during the pre copy phase of live migration. Only DMA WRITEs are logged,
1362 * When DMA logging is started a range of IOVAs to monitor is provided and the
1363 * device can optimize its logging to cover only the IOVA range given. Each
1364 * DMA that the device initiates inside the range will be logged by the device
1367 * page_size is an input that hints what tracking granularity the device
1368 * should try to achieve. If the device cannot do the hinted page size then
1369 * it's the driver choice which page size to pick based on its support.
1370 * On output the device will return the page size it selected.
1375 * The core kernel code guarantees to support by minimum num_ranges that fit
1377 * up if the above can't be achieved as of some driver limitations.
1380 * should follow at the end. Another start is not allowed in the meantime.
1403 * Upon VFIO_DEVICE_FEATURE_GET read back and clear the device DMA log
1405 * Query the device's DMA log for written pages within the given IOVA range.
1406 * During querying the log is cleared for the IOVA range.
1408 * bitmap is a pointer to an array of u64s that will hold the output bitmap
1409 * with 1 bit reporting a page_size unit of IOVA. The mapping of IOVA to bits
1413 * The input page_size can be any power of two value and does not have to
1414 * match the value given to VFIO_DEVICE_FEATURE_DMA_LOGGING_START. The driver
1415 * will format its internal logging to match the reporting page size, possibly
1416 * by replicating bits if the internal page size is lower than requested.
1418 * The LOGGING_REPORT will only set bits in the bitmap and never clear or
1419 * perform any initialization of the user provided bitmap.
1421 * If any error is returned userspace should assume that the dirty log is
1423 * restart the dirty tracking, or to abort/restart the whole migration.
1438 * Upon VFIO_DEVICE_FEATURE_GET read back the estimated data length that will
1451 * Upon VFIO_DEVICE_FEATURE_SET, set or clear the BUS mastering for the device
1452 * based on the operation specified in op flag.
1454 * The functionality is incorporated for devices that needs bus master control,
1455 * but the in-band device interface lacks the support. Consequently, it is not
1457 * in-band through the configuration space. At present, this feature is supported
1459 * When the device's BUS MASTER setting is configured as CLEAR, it will result in
1460 * blocking all incoming DMA requests from the device. On the other hand, configuring
1461 * the device's BUS MASTER setting as SET (enable) will grant the device the
1462 * capability to perform DMA to the host memory.
1476 * Retrieve information about the IOMMU object. Fills in provided
1492 * The IOVA capability allows to report the valid IOVA range(s)
1494 * devices attached to the container. Any DMA map attempt
1495 * outside the valid iova range will return error.
1497 * The structures below define version 1 of this capability.
1514 * The migration capability allows to report supported features for migration.
1516 * The structures below define version 1 of this capability.
1518 * The existence of this capability indicates that IOMMU kernel driver supports
1524 * size in bytes that can be used by user applications when getting the dirty
1537 * The DMA available capability allows to report the current number of
1540 * The structure below defines version 1 of this capability.
1542 * avail: specifies the current number of outstanding DMA mappings allowed.
1556 * Map process virtual addresses to IO virtual addresses using the
1559 * If flags & VFIO_DMA_MAP_FLAG_VADDR, update the base vaddr for iova. The vaddr
1561 * maintain memory consistency within the user application, the updated vaddr
1562 * must address the same memory object as originally mapped. Failure to do so
1564 * size must match those in the original MAP_DMA call. Protection is not
1565 * changed, and the READ & WRITE flags must be 0.
1590 * Unmap IO virtual addresses using the provided struct vfio_dma_unmap.
1591 * Caller sets argsz. The actual unmapped size is returned in the size
1592 * field. No guarantee is made to the user that arbitrary unmaps of iova
1593 * or size different from those used in the original mapping call will
1596 * VFIO_DMA_UNMAP_FLAG_GET_DIRTY_BITMAP should be set to get the dirty bitmap
1597 * before unmapping IO virtual addresses. When this flag is set, the user must
1599 * memory via vfio_bitmap.data and its size in the vfio_bitmap.size field.
1600 * A bit in the bitmap represents one page, of user provided page size in
1602 * indicates that the page at that offset from iova is dirty. A Bitmap of the
1603 * pages in the range of unmapped size is returned in the user-provided
1607 * must be 0. This cannot be combined with the get-dirty-bitmap flag.
1610 * virtual addresses in the iova range. DMA to already-mapped pages continues.
1611 * Groups may not be added to the container while any addresses are invalid.
1612 * This cannot be combined with the get-dirty-bitmap flag.
1641 * Calling the IOCTL with VFIO_IOMMU_DIRTY_PAGES_FLAG_START flag set, instructs
1642 * the IOMMU driver to log pages that are dirtied or potentially dirtied by
1643 * the device; designed to be used when a migration is in progress. Dirty pages
1644 * are logged until logging is disabled by user application by calling the IOCTL
1647 * Calling the IOCTL with VFIO_IOMMU_DIRTY_PAGES_FLAG_STOP flag set, instructs
1648 * the IOMMU driver to stop logging dirtied pages.
1650 * Calling the IOCTL with VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP flag set
1651 * returns the dirty pages bitmap for IOMMU container for a given IOVA range.
1652 * The user must specify the IOVA range and the pgsize through the structure
1653 * vfio_iommu_type1_dirty_bitmap_get in the data[] portion. This interface
1654 * supports getting a bitmap of the smallest supported pgsize only and can be
1655 * modified in future to get a bitmap of any specified supported pgsize. The
1656 * user must provide a zeroed memory area for the bitmap memory and specify its
1658 * starting from iova offset. The user should provide page size in bitmap.pgsize
1659 * field. A bit set in the bitmap indicates that the page at that offset from
1660 * iova is dirty. The caller must set argsz to a value including the size of
1661 * structure vfio_iommu_type1_dirty_bitmap_get, but excluding the size of the
1665 * Only one of the flags _START, _STOP and _GET may be specified at a time.
1688 * The SPAPR TCE DDW info struct provides the information about
1689 * the details of Dynamic DMA window capability.
1692 * @max_dynamic_windows_supported tells the maximum number of windows
1693 * which the platform can create.
1694 * @levels tells the maximum number of levels in multi-level IOMMU tables;
1696 * the amount of physically contiguous memory required for the table.
1705 * The SPAPR TCE info struct provides the information about the PCI bus
1707 * the hardware so the guest has to know that information.
1709 * The DMA 32 bit window start is an absolute PCI bus address.
1710 * The IOVA address passed via map/unmap ioctls are absolute PCI bus
1711 * addresses too so the window works as a filter rather than an offset
1715 * - VFIO_IOMMU_SPAPR_INFO_DDW: informs the userspace that dynamic DMA windows
1776 * user pages and does the locked memory accounting so
1801 * to every IOMMU group in the container. It receives page shift, window
1802 * size and number of levels in the TCE table being created.
1804 * It allocates and returns an offset on a PCI bus of the new DMA window.
1823 * Unprograms a TCE table from all groups in the container and destroys it.