| Message ID | 20250117-msm-gpu-fault-fixes-next-v1-0-bc9b332b5d0b@gmail.com |
|---|---|
| Headers | show |
| Series | iommu/arm-smmu, drm/msm: Fixes for stall-on-fault | expand |
On 2025-01-17 6:47 pm, Connor Abbott wrote: > On some SMMUv2 implementations, including MMU-500, SMMU_CBn_FSR.SS > asserts an interrupt. The only way to clear that bit is to resume the > transaction by writing SMMU_CBn_RESUME, but typically resuming the > transaction requires complex operations (copying in pages, etc.) that > can't be done in IRQ context. drm/msm already has a problem, because > its fault handler sometimes schedules a job to dump the GPU state and > doesn't resume translation until this is complete. > > Work around this by disabling context fault interrupts until after the > transaction is resumed. Because other context banks can share an IRQ > line, we may still get an interrupt intended for another context bank, > but in this case only SMMU_CBn_FSR.SS will be asserted and we can skip > it assuming that interrupts are disabled which is accomplished by > removing the bit from ARM_SMMU_CB_FSR_FAULT. > > Signed-off-by: Connor Abbott <cwabbott0@gmail.com> > --- > drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 15 +++++++++++++- > drivers/iommu/arm/arm-smmu/arm-smmu.c | 32 ++++++++++++++++++++++++++++++ > drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 +- > 3 files changed, 47 insertions(+), 2 deletions(-) > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > index 59d02687280e8d37b5e944619fcfe4ebd1bd6926..ee2fdf7e79a6d04bc2700e454253c96b573c5569 100644 > --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > @@ -125,12 +125,25 @@ static void qcom_adreno_smmu_resume_translation(const void *cookie, bool termina > struct arm_smmu_domain *smmu_domain = (void *)cookie; > struct arm_smmu_cfg *cfg = &smmu_domain->cfg; > struct arm_smmu_device *smmu = smmu_domain->smmu; > - u32 reg = 0; > + u32 reg = 0, sctlr; > + unsigned long flags; > > if (terminate) > reg |= ARM_SMMU_RESUME_TERMINATE; > > + spin_lock_irqsave(&smmu_domain->stall_lock, flags); > + > arm_smmu_cb_write(smmu, cfg->cbndx, ARM_SMMU_CB_RESUME, reg); > + > + /* > + * Re-enable interrupts after they were disabled by > + * arm_smmu_context_fault(). > + */ > + sctlr = arm_smmu_cb_read(smmu, cfg->cbndx, ARM_SMMU_CB_SCTLR); > + sctlr |= ARM_SMMU_SCTLR_CFIE; > + arm_smmu_cb_write(smmu, cfg->cbndx, ARM_SMMU_CB_SCTLR, sctlr); > + > + spin_unlock_irqrestore(&smmu_domain->stall_lock, flags); > } > > static void qcom_adreno_smmu_set_prr_bit(const void *cookie, bool set) > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c > index 79afc92e1d8b984dd35c469a3f283ad0c78f3d26..c92de760940ee2872f22dbe1b2519e02766aa143 100644 > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c > @@ -457,12 +457,43 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev) > DEFAULT_RATELIMIT_BURST); > int idx = smmu_domain->cfg.cbndx; > int ret; > + unsigned long flags; > > arm_smmu_read_context_fault_info(smmu, idx, &cfi); > > if (!(cfi.fsr & ARM_SMMU_CB_FSR_FAULT)) > return IRQ_NONE; > > + /* > + * On some implementations FSR.SS asserts a context fault > + * interrupt. We do not want this behavior, because resolving the > + * original context fault typically requires operations that cannot be > + * performed in IRQ context but leaving the stall unacknowledged will > + * immediately lead to another spurious interrupt as FSR.SS is still > + * set. Work around this by disabling interrupts for this context bank. > + * It's expected that interrupts are re-enabled after resuming the > + * translation. > + * > + * We have to do this before report_iommu_fault() so that we don't > + * leave interrupts disabled in case the downstream user decides the > + * fault can be resolved inside its fault handler. > + * > + * There is a possible race if there are multiple context banks sharing > + * the same interrupt and both signal an interrupt in between writing > + * RESUME and SCTLR. We could disable interrupts here before we > + * re-enable them in the resume handler, leaving interrupts enabled. > + * Lock the write to serialize it with the resume handler. > + */ > + if (cfi.fsr & ARM_SMMU_CB_FSR_SS) { > + u32 val; > + > + spin_lock_irqsave(&smmu_domain->stall_lock, flags); No need for _irqsave - if this IRQ handler could preempt itself, locking would be the least of our worries ;) Also I'd be inclined to just use cb_lock for this rather than add a new one. I guess there's an argument for granularity, but there's also an argument that CFIE manipulation is just another context bank operation which needs serialising against itself, and significantly rarer than the others we have already. Cheers, Robin. > + val = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_SCTLR); > + val &= ~ARM_SMMU_SCTLR_CFIE; > + arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_SCTLR, val); > + spin_unlock_irqrestore(&smmu_domain->stall_lock, flags); > + } > + > ret = report_iommu_fault(&smmu_domain->domain, NULL, cfi.iova, > cfi.fsynr & ARM_SMMU_CB_FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ); > > @@ -921,6 +952,7 @@ static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev) > > mutex_init(&smmu_domain->init_mutex); > spin_lock_init(&smmu_domain->cb_lock); > + spin_lock_init(&smmu_domain->stall_lock); > > return &smmu_domain->domain; > } > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h > index 2dbf3243b5ad2db01e17fb26c26c838942a491be..153fac131b2484d468fd482ffbf130efc8cfb8f6 100644 > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h > @@ -216,7 +216,6 @@ enum arm_smmu_cbar_type { > ARM_SMMU_CB_FSR_TLBLKF) > > #define ARM_SMMU_CB_FSR_FAULT (ARM_SMMU_CB_FSR_MULTI | \ > - ARM_SMMU_CB_FSR_SS | \ > ARM_SMMU_CB_FSR_UUT | \ > ARM_SMMU_CB_FSR_EF | \ > ARM_SMMU_CB_FSR_PF | \ > @@ -384,6 +383,7 @@ struct arm_smmu_domain { > enum arm_smmu_domain_stage stage; > struct mutex init_mutex; /* Protects smmu pointer */ > spinlock_t cb_lock; /* Serialises ATS1* ops and TLB syncs */ > + spinlock_t stall_lock; > struct iommu_domain domain; > }; > >
drm/msm uses the stall-on-fault model to record the GPU state on the first GPU page fault to help debugging. On systems where the GPU is paired with a MMU-500, there were two problems: 1. The MMU-500 doesn't de-assert its interrupt line until the fault is resumed, which led to a storm of interrupts until the fault handler was called. If we got unlucky and the fault handler was on the same CPU as the interrupt, there was a deadlock. 2. The GPU is capable of generating page faults much faster than we can resume them. GMU (GPU Management Unit) shares the same context bank as the GPU, so if there was a sudden spurt of page faults it would be effectively starved and would trigger a watchdog reset, made even worse because the GPU cannot be reset while there's a pending transaction leaving the GPU permanently wedged. Patch 1 fixes the first problem and is independent of the rest of the series. Patch 3 fixes the second problem and is dependent on patch 2, so there will have to be some cross-tree coordination. I've rebased this series on the latest linux-next to avoid rebase troubles. Signed-off-by: Connor Abbott <cwabbott0@gmail.com> --- Connor Abbott (3): iommu/arm-smmu: Fix spurious interrupts with stall-on-fault iommu/arm-smmu-qcom: Make set_stall work when the device is on drm/msm: Temporarily disable stall-on-fault after a page fault drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 ++ drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +++ drivers/gpu/drm/msm/adreno/adreno_gpu.c | 56 +++++++++++++++++++++++++++++- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 21 +++++++++++ drivers/gpu/drm/msm/msm_iommu.c | 9 +++++ drivers/gpu/drm/msm/msm_mmu.h | 1 + drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 46 +++++++++++++++++++++--- drivers/iommu/arm/arm-smmu/arm-smmu.c | 32 +++++++++++++++++ drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 +- 9 files changed, 167 insertions(+), 6 deletions(-) --- base-commit: 0907e7fb35756464aa34c35d6abb02998418164b change-id: 20250117-msm-gpu-fault-fixes-next-96e3098023e1 Best regards,