include/uapi/linux/iommufd.h
Source file repositories/reference/linux-study-clean/include/uapi/linux/iommufd.h
File Facts
- System
- Linux kernel
- Corpus path
include/uapi/linux/iommufd.h- Extension
.h- Size
- 51648 bytes
- Lines
- 1355
- Domain
- Core OS
- Bucket
- Core Kernel Interface
- Inferred role
- Core OS: implementation source
- Status
- source implementation candidate
Why This File Exists
Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/ioctl.hlinux/types.h
Detected Declarations
struct iommu_destroystruct iommu_ioas_allocstruct iommu_iova_rangestruct iommu_ioas_iova_rangesstruct iommu_ioas_allow_iovasstruct iommu_ioas_mapstruct iommu_ioas_map_filestruct iommu_ioas_copystruct iommu_ioas_unmapstruct iommu_optionstruct iommu_vfio_ioasstruct iommu_hwpt_vtd_s1struct iommu_hwpt_arm_smmuv3struct iommu_hwpt_amd_gueststruct iommu_hwpt_allocstruct iommu_hw_info_vtdstruct iommu_hw_info_arm_smmuv3struct iommu_hw_info_tegra241_cmdqvstruct iommu_hw_info_amdstruct iommu_hw_infostruct iommu_hwpt_set_dirty_trackingstruct iommu_hwpt_get_dirty_bitmapstruct iommu_hwpt_vtd_s1_invalidatestruct iommu_viommu_arm_smmuv3_invalidatestruct iommu_hwpt_invalidatestruct iommu_hwpt_pgfaultstruct iommu_hwpt_page_responsestruct iommu_fault_allocstruct iommu_viommu_tegra241_cmdqvstruct iommu_viommu_allocstruct iommu_vdevice_allocstruct iommu_ioas_change_processstruct iommufd_vevent_headerstruct iommu_vevent_arm_smmuv3struct iommu_vevent_tegra241_cmdqvstruct iommu_veventq_allocstruct iommu_hw_queue_allocenum iommufd_ioas_map_flagsenum iommufd_optionenum iommufd_option_opsenum iommufd_vfio_ioas_openum iommufd_hwpt_alloc_flagsenum iommu_hwpt_vtd_s1_flagsenum iommu_hwpt_data_typeenum iommu_hw_info_vtd_flagsenum iommu_hw_info_typeenum iommufd_hw_capabilitiesenum iommufd_hw_info_flags
Annotated Snippet
struct iommu_destroy {
__u32 size;
__u32 id;
};
#define IOMMU_DESTROY _IO(IOMMUFD_TYPE, IOMMUFD_CMD_DESTROY)
/**
* struct iommu_ioas_alloc - ioctl(IOMMU_IOAS_ALLOC)
* @size: sizeof(struct iommu_ioas_alloc)
* @flags: Must be 0
* @out_ioas_id: Output IOAS ID for the allocated object
*
* Allocate an IO Address Space (IOAS) which holds an IO Virtual Address (IOVA)
* to memory mapping.
*/
struct iommu_ioas_alloc {
__u32 size;
__u32 flags;
__u32 out_ioas_id;
};
#define IOMMU_IOAS_ALLOC _IO(IOMMUFD_TYPE, IOMMUFD_CMD_IOAS_ALLOC)
/**
* struct iommu_iova_range - ioctl(IOMMU_IOVA_RANGE)
* @start: First IOVA
* @last: Inclusive last IOVA
*
* An interval in IOVA space.
*/
struct iommu_iova_range {
__aligned_u64 start;
__aligned_u64 last;
};
/**
* struct iommu_ioas_iova_ranges - ioctl(IOMMU_IOAS_IOVA_RANGES)
* @size: sizeof(struct iommu_ioas_iova_ranges)
* @ioas_id: IOAS ID to read ranges from
* @num_iovas: Input/Output total number of ranges in the IOAS
* @__reserved: Must be 0
* @allowed_iovas: Pointer to the output array of struct iommu_iova_range
* @out_iova_alignment: Minimum alignment required for mapping IOVA
*
* Query an IOAS for ranges of allowed IOVAs. Mapping IOVA outside these ranges
* is not allowed. num_iovas will be set to the total number of iovas and
* the allowed_iovas[] will be filled in as space permits.
*
* The allowed ranges are dependent on the HW path the DMA operation takes, and
* can change during the lifetime of the IOAS. A fresh empty IOAS will have a
* full range, and each attached device will narrow the ranges based on that
* device's HW restrictions. Detaching a device can widen the ranges. Userspace
* should query ranges after every attach/detach to know what IOVAs are valid
* for mapping.
*
* On input num_iovas is the length of the allowed_iovas array. On output it is
* the total number of iovas filled in. The ioctl will return -EMSGSIZE and set
* num_iovas to the required value if num_iovas is too small. In this case the
* caller should allocate a larger output array and re-issue the ioctl.
*
* out_iova_alignment returns the minimum IOVA alignment that can be given
* to IOMMU_IOAS_MAP/COPY. IOVA's must satisfy::
*
* starting_iova % out_iova_alignment == 0
* (starting_iova + length) % out_iova_alignment == 0
*
* out_iova_alignment can be 1 indicating any IOVA is allowed. It cannot
* be higher than the system PAGE_SIZE.
*/
struct iommu_ioas_iova_ranges {
__u32 size;
__u32 ioas_id;
__u32 num_iovas;
__u32 __reserved;
__aligned_u64 allowed_iovas;
__aligned_u64 out_iova_alignment;
};
#define IOMMU_IOAS_IOVA_RANGES _IO(IOMMUFD_TYPE, IOMMUFD_CMD_IOAS_IOVA_RANGES)
/**
* struct iommu_ioas_allow_iovas - ioctl(IOMMU_IOAS_ALLOW_IOVAS)
* @size: sizeof(struct iommu_ioas_allow_iovas)
* @ioas_id: IOAS ID to allow IOVAs from
* @num_iovas: Input/Output total number of ranges in the IOAS
* @__reserved: Must be 0
* @allowed_iovas: Pointer to array of struct iommu_iova_range
*
* Ensure a range of IOVAs are always available for allocation. If this call
* succeeds then IOMMU_IOAS_IOVA_RANGES will never return a list of IOVA ranges
* that are narrower than the ranges provided here. This call will fail if
* IOMMU_IOAS_IOVA_RANGES is currently narrower than the given ranges.
Annotation
- Immediate include surface: `linux/ioctl.h`, `linux/types.h`.
- Detected declarations: `struct iommu_destroy`, `struct iommu_ioas_alloc`, `struct iommu_iova_range`, `struct iommu_ioas_iova_ranges`, `struct iommu_ioas_allow_iovas`, `struct iommu_ioas_map`, `struct iommu_ioas_map_file`, `struct iommu_ioas_copy`, `struct iommu_ioas_unmap`, `struct iommu_option`.
- Atlas domain: Core OS / Core Kernel Interface.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.