On Tue, Nov 05, 2024 at 12:04:29PM -0800, Nicolin Chen wrote:
With the introduction of the new object and its infrastructure, update the doc to reflect that and add a new graph.
Reviewed-by: Jason Gunthorpe jgg@nvidia.com Reviewed-by: Kevin Tian kevin.tian@intel.com Signed-off-by: Nicolin Chen nicolinc@nvidia.com
Documentation/userspace-api/iommufd.rst | 69 ++++++++++++++++++++++++- 1 file changed, 68 insertions(+), 1 deletion(-)
diff --git a/Documentation/userspace-api/iommufd.rst b/Documentation/userspace-api/iommufd.rst index 2deba93bf159..a8b7766c2849 100644 --- a/Documentation/userspace-api/iommufd.rst +++ b/Documentation/userspace-api/iommufd.rst @@ -63,6 +63,37 @@ Following IOMMUFD objects are exposed to userspace: space usually has mappings from guest-level I/O virtual addresses to guest- level physical addresses. +- IOMMUFD_OBJ_VIOMMU, representing a slice of the physical IOMMU instance,
- passed to or shared with a VM. It may be some HW-accelerated virtualization
- features and some SW resources used by the VM. For examples:
- Security namespace for guest owned ID, e.g. guest-controlled cache tags
- Non-device-affiliated event reporting, e.g. invalidation queue errors
- Access to a sharable nesting parent pagetable across physical IOMMUs
- Virtualization of various platforms IDs, e.g. RIDs and others
- Delivery of paravirtualized invalidation
- Direct assigned invalidation queues
- Direct assigned interrupts
The bullet list above is outputted in htmldocs build as long-running paragraph instead.
- Such a vIOMMU object generally has the access to a nesting parent pagetable
- to support some HW-accelerated virtualization features. So, a vIOMMU object
- must be created given a nesting parent HWPT_PAGING object, and then it would
- encapsulate that HWPT_PAGING object. Therefore, a vIOMMU object can be used
- to allocate an HWPT_NESTED object in place of the encapsulated HWPT_PAGING.
Thanks.