On Fri, Jun 04, 2021 at 09:22:43AM -0700, Jacob Pan wrote: > Hi Jason, > > On Fri, 4 Jun 2021 09:30:37 +0800, Jason Wang <jasowang@xxxxxxxxxx> wrote: > > > 在 2021/6/4 上午2:19, Jacob Pan 写道: > > > Hi Shenming, > > > > > > On Wed, 2 Jun 2021 12:50:26 +0800, Shenming Lu <lushenming@xxxxxxxxxx> > > > wrote: > > > > > >> On 2021/6/2 1:33, Jason Gunthorpe wrote: > > >>> On Tue, Jun 01, 2021 at 08:30:35PM +0800, Lu Baolu wrote: > > >>> > > >>>> The drivers register per page table fault handlers to /dev/ioasid > > >>>> which will then register itself to iommu core to listen and route > > >>>> the per- device I/O page faults. > > >>> I'm still confused why drivers need fault handlers at all? > > >> Essentially it is the userspace that needs the fault handlers, > > >> one case is to deliver the faults to the vIOMMU, and another > > >> case is to enable IOPF on the GPA address space for on-demand > > >> paging, it seems that both could be specified in/through the > > >> IOASID_ALLOC ioctl? > > >> > > > I would think IOASID_BIND_PGTABLE is where fault handler should be > > > registered. There wouldn't be any IO page fault without the binding > > > anyway. > > > > > > I also don't understand why device drivers should register the fault > > > handler, the fault is detected by the pIOMMU and injected to the > > > vIOMMU. So I think it should be the IOASID itself register the handler. > > > > > > > > > As discussed in another thread. > > > > I think the reason is that ATS doesn't forbid the #PF to be reported via > > a device specific way. > > Yes, in that case we should support both. Give the device driver a chance > to handle the IOPF if it can. Huh? The device driver does not "handle the IOPF" the device driver might inject the IOPF. Jason
