Re: [PATCH] iommufd: Deal with IOMMU_HWPT_FAULT_ID_VALID in iommufd core

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Dec 09, 2024 at 10:51:51AM +0800, Yi Liu wrote:
> On 2024/12/9 09:08, Baolu Lu wrote:
> > On 12/7/24 20:01, Yi Liu wrote:
> > > IOMMU_HWPT_FAULT_ID_VALID is used to mark if the fault_id field of
> > > iommu_hwp_alloc is valid or not. As the fault_id field is handled in
> > > the iommufd core, so it makes sense to sanitize the
> > > IOMMU_HWPT_FAULT_ID_VALID flag in the iommufd core, and mask it out
> > > before passing the user flags to the iommu drivers.
> > 
> > Is it a valid use case for an iommu driver to intercept the
> > IOMMU_HWPT_FAULT_ID_VALID flag as an indication that user space requests
> > an iopf-capable domain?

For now we have no use case, so we can drop it from drivers, I think.

PRI support or not is decided when the domain is attached based on the
fault_handler in the struct iommu_domain.

As a general rule drivers should not know the *userspace* is doing
something as much as we can manage.

> > If the device and its associated iommu do not support PRI, the domain
> > allocation should be aborted and a failure returned?
 
> Agreed, it is better to fail the hwpt allocation. BTW. We may also check it
> by reading the enable bit in PCI config space of the device. Which one
> would be better?

We should not be reading pci config space in iommufd. iommufd is
generic and not tied to PCI.

It would be nice if domain allocation fails, but also I wouldn't
contort things to achieve that. Failing attach is also OK and must
also be supported as a fault capable domain allocated on a fault
capable device can still fail to be attached to a non fault capable
device.

"fault capable" is complicated unfortunately because we have driver
specific page fault reporting, and it may be that vfio userspace is
processing fault...

Jason