On Fri, Dec 08, 2023 at 01:57:26PM +0800, Baolu Lu wrote:
On 12/1/23 10:24 PM, Jason Gunthorpe wrote:
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.
When an IO page fault occurs on the first-stage translation table, the IOMMU hardware can deliver the page fault to user space through the IOMMUFD framework. User space can then handle the page fault and respond to the device top-down through the IOMMUFD. This allows user space to implement its own IO page fault handling policies.
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 probably backwards, userspace should allocate the FD with a dedicated ioctl and provide it during domain allocation.
Introducing a dedicated fault FD for fault handling seems promising. It decouples the fault handling from any specific domain. I suppose we need different fault fd for recoverable faults (a.k.a. IO page fault) and unrecoverable faults. Do I understand you correctly?
I haven't thought that far ahead :) Once you have a generic fault FD concept it can be sliced in different ways. If there is a technical need to seperate recoverable/unrecoverable then the FD flavour should be specified during FD creation. Otherwise just let userspace do whatever it wants.
Jason