| Message ID | 20210401154718.307519-1-jean-philippe@linaro.org |
|---|---|
| Headers | show |
| Series | iommu: I/O page faults for SMMUv3 | expand |
On Thu, Apr 01, 2021 at 05:47:19PM +0200, Jean-Philippe Brucker wrote: > The SMMU provides a Stall model for handling page faults in platform > devices. It is similar to PCIe PRI, but doesn't require devices to have > their own translation cache. Instead, faulting transactions are parked > and the OS is given a chance to fix the page tables and retry the > transaction. > > Enable stall for devices that support it (opt-in by firmware). When an > event corresponds to a translation error, call the IOMMU fault handler. > If the fault is recoverable, it will call us back to terminate or > continue the stall. Which hardware is this useful for? Stalling adds a fair amount of complexity to the driver, so I don't think we should support it unless we're likely to see platforms that both implement it and do something useful with it. Will
Hi, Will On 2021/4/2 上午1:11, Will Deacon wrote: > On Thu, Apr 01, 2021 at 05:47:19PM +0200, Jean-Philippe Brucker wrote: >> The SMMU provides a Stall model for handling page faults in platform >> devices. It is similar to PCIe PRI, but doesn't require devices to have >> their own translation cache. Instead, faulting transactions are parked >> and the OS is given a chance to fix the page tables and retry the >> transaction. >> >> Enable stall for devices that support it (opt-in by firmware). When an >> event corresponds to a translation error, call the IOMMU fault handler. >> If the fault is recoverable, it will call us back to terminate or >> continue the stall. > Which hardware is this useful for? Stalling adds a fair amount of complexity > to the driver, so I don't think we should support it unless we're likely to > see platforms that both implement it and do something useful with it. I have tested the stall mode on Hisilicon Kunpeng920 board, as well as using drivers/misc/uacce/uacce.c. Thanks
On Thu, Apr 01, 2021 at 06:15:02PM +0100, Will Deacon wrote: > On Thu, Apr 01, 2021 at 05:47:09PM +0200, Jean-Philippe Brucker wrote: > > Add stall support to the SMMUv3 driver, along with a common I/O Page > > Fault handler. > > > > Since [v13] I added review and ack tags (Thanks!), and a lockdep_assert. > > It would be good to have all of it in v5.13, since patch 10 introduces > > the first user for the IOPF interface from patch 6. But if that's not > > possible, please pick patches 1-6 so the Vt-d driver can start using > > them. > > Patches 1-7 look good to me, but I'm not convinced about the utility of > stalling faults so I'd prefer the later patches to come along with a > real user. As others said, it is possible to assign queues from the compression and crypto accelerators on the Kunpeng920 to userspace, using the uacce char device (upstream since last year, but waiting for implementations of the SVA API in IOMMU drivers). I've been using that platform for testing my code for the past year, with the UADK tool as well as an openssl plugin. Securely assignig a queue to userspace requires full SVA support in SMMUv3, which consists of PASID, page table sharing, and I/O page faults. The first two were already merged, and the third one requires either Stall or PRI. I'm not submitting PRI support at the moment because there is no hardware, but the Hisilicon platform implements stall and will be able to use it right away. Thanks, Jean
On Thu, Apr 01, 2021 at 05:47:09PM +0200, Jean-Philippe Brucker wrote: > Jean-Philippe Brucker (10): > iommu: Fix comment for struct iommu_fwspec > iommu/arm-smmu-v3: Use device properties for pasid-num-bits > iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA > iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF > uacce: Enable IOMMU_DEV_FEAT_IOPF > iommu: Add a page fault handler > iommu/arm-smmu-v3: Maintain a SID->device structure Applied the first 7 patches, thanks.