On 20/11/2019 3:11 pm, Will Deacon wrote:
On Mon, Nov 04, 2019 at 04:27:56PM -0700, Jordan Crouse wrote:
On Mon, Nov 04, 2019 at 07:14:45PM +0000, Will Deacon wrote:
On Fri, Oct 25, 2019 at 07:08:38PM +0100, Robin Murphy wrote:
diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
index 9a57eb6c253c..059be7e21030 100644
--- a/drivers/iommu/qcom_iommu.c
+++ b/drivers/iommu/qcom_iommu.c
@@ -271,15 +271,13 @@ static int qcom_iommu_init_domain(struct iommu_domain
*domain,
iommu_writeq(ctx, ARM_SMMU_CB_TTBR0,
pgtbl_cfg.arm_lpae_s1_cfg.ttbr |
FIELD_PREP(TTBRn_ASID, ctx->asid));
- iommu_writeq(ctx, ARM_SMMU_CB_TTBR1,
- FIELD_PREP(TTBRn_ASID, ctx->asid));
+ iommu_writeq(ctx, ARM_SMMU_CB_TTBR1, 0);
Are you sure it's safe to drop the ASID here? Just want to make sure there
wasn't some "quirk" this was helping with.
I was reminded of this recently. Some of our SMMU guys told me that a 0x0 in
TTBR1 could cause a S2 fault if a faulty transaction caused a ttbr1 lookup so
the "quirk" was writing the ASID so the register wasn't zero. I'm not sure if
this is a vendor specific blip or not.
You should be able to set EPD1 to prevent walks via TTBR1 in that case,
though. Sticking the ASID in there is still dodgy if EPD1 is clear and
TTBR1 points at junk (or even physical address 0x0).
That's probably something which should be folded into this patch.
Note that EPD1 was being set by io-pgtable-arm before this patch, and
remains set by virtue of arm_smmu_lpae_tcr() afterwards, so presumably
the brokenness might run a bit deeper than that. Either way, though, I'm
somewhat dubious since the ASID could well be 0 anyway :/
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
