iommu/arm-smmu-v3: Support guest-level Realm VSMMU (Part-1)
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v3 Latest7 patches 0 repliesNew
- v27 patches 2 repliesSuperseded
- v18 patches 17 repliesSuperseded
Changes in v3 from the cover letter
* Add Acked-by from Marek
* Disable and enable ATS for T=0 devices across a PCI reset
* Rename dma_require_decrypted() to dma_require_unencrypted()
* Explain the minimum STU used to enable ATS while TDISP is T=0
Patches in v3 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/7 | firmware: arm_rmm: Add VSMMU commands and fieldsinclude/ include/ | +49 | 0 replies | |
| 2/7 | dma-mapping: Let a device declare that it reaches private memoryinclude/ include/ kernel/ | +29 | 0 replies | |
| 3/7 | dma-mapping: Keep DMA memory private for capable devicesinclude/ kernel/ kernel/ +1 more | +19 | 0 replies | |
| 4/7 | iommu: Let a driver mark an IOMMU as confidentialdrivers/ include/ | +30 | 0 replies | |
| 5/7 | iommu: Introduce TDISP T=0 state for confidential IOMMUsdrivers/ drivers/ drivers/ +2 more | +117 | 0 replies | |
| 6/7 | iommu: Park TDISP T=0 devices in the blocking domaindrivers/ | +51 | 0 replies | |
| 7/7 | iommu/arm-smmu-v3: Probe a guest-level Realm VSMMU via RSI commandsdrivers/ | +62 | 0 replies |
Reviews trailers per patch
1 of 7 patches has a Reviewed-by or Acked-by.
| Patch | Marek Szyprowski |
|---|---|
| 1/7 | |
| 2/7 | A-b |
| 3/7 | |
| 4/7 | |
| 5/7 | |
| 6/7 | |
| 7/7 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH v3 0/7] iommu/arm-smmu-v3: Support guest-level Realm VSMMU (Part-1)
This series prepares Realm guest IOMMU and DMA subsystems for devices that are present but not yet inside the Realm trust boundary.
Inside a confidential guest, we expect that all the iommus are going to be T=1 aware; there seems to be no interest in supporting IOMMUs that handle T=0 only. This means they only work on devices that have been put into the run state and issue T=1 transactions.
Today an iommu driver assumes it translates for every device behind it: it probes the device, takes a translating default domain, and puts the DMA API on its page tables. That assumption is wrong for T=0 devices, whose DMA the hypervisor translates instead, so the mappings made by the guest are never consulted and the device silently stops working.
To solve this problem, make TDISP T=0 the default for devices associated with a confidential IOMMU. The tdisp_t1 flag records the future T=1 state.
While T=0, the device remains outside the Realm trust boundary. Its DMA is translated by the host or hypervisor:
[device: T=0] ===> [hypervisor] ===> [memory]
|
+-- (guest association) --> [confidential IOMMU: blocking DMA]
Legend: ===> DMA path; --> guest topology and controlAfter reaching T=1, the device is inside the Realm trust boundary. Its DMA may use the guest VSMMU after RMM binds the device to its virtual stream:
[device] ===> [VSMMU: S1] ===> [RMM/PSMMU: S2 + DPT] ===> [memory]
As part 1 of Realm VSMMU support, implement enough core infrastructure to manage a confidential vIOMMU:
- Detect and mark it as confidential in the core iommu structures
- Support devices in T=0 mode by keeping the DMA API in direct mode. The iommu is up and running, but parks such a device in its blocking domain and translates for nothing, as the core takes over what the device still needs, which today is ATS
- Keep it parked: refuse a translating domain by every route in, whether through the default domain, sysfs, group attach or replace, or PASID
Part 1 only adds the helpers required for T=0 setup and teardown. It does not add iommu_tdisp_enter_t1() until part 2 has a transition to perform.
Then implement SMMUv3 support:
- Let a CPU-integrated IOMMU declare that its DMA can reach private memory, so coherent allocations and streaming mappings avoid the SWIOTLB shared pool
- Identify a T=1 VSMMU using trusted RSI because firmware does not distinguish it from a normal T=0 SMMU
- Validate the firmware MMIO range against RSI before activating the VSMMU and allocating its queues and tables from private memory
The series is on github:
https://github.com/nicolinc/iommufd/commits/smmuv3_realm_guest_p1-v3
Changelog
v3:
* Add Acked-by from Marek
* Disable and enable ATS for T=0 devices across a PCI reset
* Rename dma_require_decrypted() to dma_require_unencrypted()
* Explain the minimum STU used to enable ATS while TDISP is T=0
v2:
https://lore.kernel.org/all/[email protected]/
* Rebase on v7.4-rc1
* Drop Assisted-by tags
* Drop Aneesh's firmware patch that was merged
* Skip Tegra CMDQV implementation in the realm world
* Use arm_smccc_1_2_smc() to zero inputs as RMM spec demands
* Add missing iommu_using_t0_stream() check in iommu_dma_prepare_msi()
v1:
https://lore.kernel.org/all/[email protected]/
Future work
===========
Part 2 will add the T=1 transition after validation through:
- TSM, whose guest-side interface remains under discussion
- RMM, using the Arm-specific RSI VDEV command
For a multi-device IOMMU group, the first device accepted into T=1 claims the group. Part 2 will reject T=1 for every other member.
The current RSI binding validation returns one VSID, so part 2 must reject a firmware specification containing multiple SIDs upon the T=1 transition.
Nicolin Chen (7):
firmware: arm_rmm: Add VSMMU commands and fields
dma-mapping: Let a device declare that it reaches private memory
dma-mapping: Keep DMA memory private for capable devices
iommu: Let a driver mark an IOMMU as confidential
iommu: Introduce TDISP T=0 state for confidential IOMMUs
iommu: Park TDISP T=0 devices in the blocking domain iommu/arm-smmu-v3: Probe a guest-level Realm VSMMU via RSI commands
drivers/iommu/Makefile | 3 + drivers/iommu/iommu-priv.h | 19 ++++ include/linux/arm-rsi-cmds.h | 29 ++++++ include/linux/arm-smccc-rsi.h | 20 ++++ include/linux/device.h | 4 + include/linux/dma-direct.h | 7 +- include/linux/dma-mapping.h | 4 + include/linux/iommu.h | 14 +++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 64 +++++++++++- drivers/iommu/iommu-cc.c | 63 ++++++++++++ drivers/iommu/iommu.c | 104 +++++++++++++++++++- kernel/dma/direct.c | 21 ++-- kernel/dma/mapping.c | 23 ++++- kernel/dma/swiotlb.c | 2 +- 14 files changed, 357 insertions(+), 20 deletions(-) create mode 100644 drivers/iommu/iommu-cc.c
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
Signature · 1 line
2.43.0