Jason Gunthorpe
2023-Nov-02 12:47 UTC
[PATCH v2 0/6] IOMMUFD: Deliver IO page faults to user space
On Thu, Oct 26, 2023 at 10:49:24AM +0800, Lu Baolu wrote:> Hi folks, > > This series implements the functionality of delivering IO page faults to > user space through the IOMMUFD framework for nested translation. Nested > translation is a hardware feature that supports two-stage translation > tables for IOMMU. The second-stage translation table is managed by the > host VMM, while the first-stage translation table is owned by user > space. This allows user space to control the IOMMU mappings for its > devices.Having now looked more closely at the ARM requirements it seems we will need generic events, not just page fault events to have a complete emulation. So I'd like to see this generalized into a channel to carry any events..> User space indicates its capability of handling IO page faults by > setting the IOMMU_HWPT_ALLOC_IOPF_CAPABLE flag when allocating a > hardware page table (HWPT). IOMMUFD will then set up its infrastructure > for page fault delivery. On a successful return of HWPT allocation, the > user can retrieve and respond to page faults by reading and writing to > the file descriptor (FD) returned in out_fault_fd.This is the right way to approach it, and more broadly this shouldn't be an iommufd specific thing. Kernel drivers will also need to create fault capable PAGING iommu domains. Jason
Tian, Kevin
2023-Nov-07 08:35 UTC
[PATCH v2 0/6] IOMMUFD: Deliver IO page faults to user space
> From: Jason Gunthorpe <jgg at ziepe.ca> > Sent: Thursday, November 2, 2023 8:48 PM > > On Thu, Oct 26, 2023 at 10:49:24AM +0800, Lu Baolu wrote: > > Hi folks, > > > > This series implements the functionality of delivering IO page faults to > > user space through the IOMMUFD framework for nested translation. > Nested > > translation is a hardware feature that supports two-stage translation > > tables for IOMMU. The second-stage translation table is managed by the > > host VMM, while the first-stage translation table is owned by user > > space. This allows user space to control the IOMMU mappings for its > > devices. > > Having now looked more closely at the ARM requirements it seems we > will need generic events, not just page fault events to have a > complete emulation.Can you elaborate?> > So I'd like to see this generalized into a channel to carry any > events.. > > > User space indicates its capability of handling IO page faults by > > setting the IOMMU_HWPT_ALLOC_IOPF_CAPABLE flag when allocating a > > hardware page table (HWPT). IOMMUFD will then set up its infrastructure > > for page fault delivery. On a successful return of HWPT allocation, the > > user can retrieve and respond to page faults by reading and writing to > > the file descriptor (FD) returned in out_fault_fd. > > This is the right way to approach it, and more broadly this shouldn't > be an iommufd specific thing. Kernel drivers will also need to create > fault capable PAGING iommu domains. >Are you suggesting a common interface used by both iommufd and kernel drivers? but I didn't get the last piece. If those domains are created by kernel drivers why would they require a uAPI for userspace to specify fault capable?
Maybe Matching Threads
- [PATCH v2 0/6] IOMMUFD: Deliver IO page faults to user space
- [RFC PATCHES 00/17] IOMMUFD: Deliver IO page faults to user space
- [PATCH v3 00/10] Let iommufd charge IOPTE allocations to the memory cgroup
- [PATCH v3 00/10] Let iommufd charge IOPTE allocations to the memory cgroup
- [PATCH 0/8] Let iommufd charge IOPTE allocations to the memory cgroup