On Mon, Jun 26, 2023 at 11:10:22AM +0800, Baolu Lu wrote: > > > > I think that, whether the guest has an IOPF capability or not, > > > > the host should always forward any stage-1 fault/error back to > > > > the guest. Yet, the implementation of this series builds with > > > > the IOPF framework that doesn't report IOMMU_FAULT_DMA_UNRECOV. > > > > > > > > And I have my doubt at the using the IOPF framework with that > > > > IOMMU_PAGE_RESP_ASYNC flag: using the IOPF framework is for > > > > its bottom half workqueue, because a page response could take > > > > a long cycle. But adding that flag feels like we don't really > > > > need the bottom half workqueue, i.e. losing the point of using > > > > the IOPF framework, IMHO. > > > > > > > > Combining the two facts above, I wonder if we really need to > > > > go through the IOPF framework; can't we just register a user > > > > fault handler in the iommufd directly upon a valid event_fd? > > > Agreed. We should avoid workqueue in sva iopf framework. Perhaps we > > > could go ahead with below code? It will be registered to device with > > > iommu_register_device_fault_handler() in IOMMU_DEV_FEAT_IOPF enabling > > > path. Un-registering in the disable path of cause. > > Well, for a virtualization use case, I still think it's should > > be registered in iommufd. > > Emm.. you suggest iommufd calls iommu_register_device_fault_handler() to > register its own page fault handler, right? > > I have a different opinion, iommu_register_device_fault_handler() is > called to register a fault handler for a device. It should be called > or initiated by a device driver. The iommufd only needs to install a > per-domain io page fault handler. > > I am considering a use case on Intel platform. Perhaps it's similar > on other platforms. An SIOV-capable device can support host SVA and > assigning mediated devices to user space at the same time. Both host > SVA and mediated devices require IOPF. So there will be multiple places > where a page fault handler needs to be registered. Okay, the narrative makes sense to me. I was more thinking of the nesting case. The iommu_register_device_fault_handler() is registered per device, as its name implies, while the handler probably should be slightly different by the attaching domain. It seems that your io_pgfault_handler() in the previous email can potentially handle this, i.e. a IOMMU_DOMAIN_NESTED could set domain->iopf_handler to forward DMA faults to user space. We just need to make sure this pathway would be unconditional at the handler registration and fault->type. > > Having a device without an IOPF/PRI > > capability, a guest OS should receive some faults too, if that > > device causes a translation failure. > > Yes. DMA faults are also a consideration. But I would like to have it > supported in a separated series. As I explained in the previous reply, > we also need to consider the software nested translation case. I see. Thanks Nic
