Messages in this thread | | | Date | Thu, 1 Apr 2021 10:42:36 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs |
| |
On Thu, Apr 01, 2021 at 01:38:46PM +0000, Liu, Yi L wrote: > > From: Jean-Philippe Brucker <jean-philippe@linaro.org> > > Sent: Thursday, April 1, 2021 8:05 PM > [...] > > > > Also wondering about: > > > > * Querying IOMMU nesting capabilities before binding page tables (which > > page table formats are supported?). We were planning to have a VFIO cap, > > but I'm guessing we need to go back to the sysfs solution? > > I think it can also be with /dev/ioasid.
Sure, anything to do with page table formats and setting page tables should go through ioasid.
> > * Invalidation, probably an ioasid_fd ioctl? > > yeah, if we are doing bind/unbind_pagtable via ioasid_fd, then yes, > invalidation should go this way as well. This is why I worried it may > fail to meet the requirement from you and Eric.
Yes, all manipulation of page tables, including removing memory ranges, or setting memory ranges to trigger a page fault behavior should go through here.
> > * Page faults, page response. From and to devices, and don't necessarily > > have a PASID. But needed by vdpa as well, so that's also going through > > /dev/ioasid? > > page faults should still be per-device, but the fault event fd may be stored > in /dev/ioasid. page response would be in /dev/ioasid just like invalidation.
Here you mean non-SVA page faults that are delegated to userspace to handle?
Why would that be per-device?
Can you show the flow you imagine?
Jason
| |