diff options
author | Zhen Lei <thunder.leizhen@huawei.com> | 2018-10-31 07:02:07 +0300 |
---|---|---|
committer | Will Deacon <will.deacon@arm.com> | 2018-12-10 17:55:58 +0300 |
commit | 84a9a75774961612d0c7dd34a1777e8f98a65abd (patch) | |
tree | 05efc386c3cc2ae62fddfdf053ab301b095a44cb /drivers/iommu/arm-smmu-v3.c | |
parent | 3cd508a8c1379427afb5e16c2e0a7c986d907853 (diff) | |
download | linux-84a9a75774961612d0c7dd34a1777e8f98a65abd.tar.xz |
iommu/arm-smmu-v3: Avoid memory corruption from Hisilicon MSI payloads
The GITS_TRANSLATER MMIO doorbell register in the ITS hardware is
architected to be 4 bytes in size, yet on hi1620 and earlier, Hisilicon
have allocated the adjacent 4 bytes to carry some IMPDEF sideband
information which results in an 8-byte MSI payload being delivered when
signalling an interrupt:
MSIAddr:
|----4bytes----|----4bytes----|
| MSIData | IMPDEF |
This poses no problem for the ITS hardware because the adjacent 4 bytes
are reserved in the memory map. However, when delivering MSIs to memory,
as we do in the SMMUv3 driver for signalling the completion of a SYNC
command, the extended payload will corrupt the 4 bytes adjacent to the
"sync_count" member in struct arm_smmu_device. Fortunately, the current
layout allocates these bytes to padding, but this is fragile and we
should make this explicit.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
[will: Rewrote commit message and comment]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Diffstat (limited to 'drivers/iommu/arm-smmu-v3.c')
-rw-r--r-- | drivers/iommu/arm-smmu-v3.c | 6 |
1 files changed, 5 insertions, 1 deletions
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index 71eda422c926..62ef4afc9ee5 100644 --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -576,7 +576,11 @@ struct arm_smmu_device { struct arm_smmu_strtab_cfg strtab_cfg; - u32 sync_count; + /* Hi16xx adds an extra 32 bits of goodness to its MSI payload */ + union { + u32 sync_count; + u64 padding; + }; /* IOMMU core code handle */ struct iommu_device iommu; |