RFC SMMUv3 driver and the supporting framework
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 RFC Latest7 patches 26 repliesIn review
- v1 RFC6 patches 29 repliesSuperseded
Patches in v2 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/7 | passthrough/arm: Modify SMMU driver to use generic device definitionxen/ | +6 | 0 replies | |
| 2/7 | arm64: Add definitions for fwnode_handlexen/ xen/ | +35 | 4 replies | |
| 3/7 | xen/passthrough/arm: Introduce iommu_fwspecxen/ xen/ xen/ | +96 | 3 replies | |
| 4/7 | ACPI: arm: Support for IORTxen/ xen/ | +1019 | 0 replies | |
| 5/7 | acpi:arm64: Add support for parsing IORT tablexen/ xen/ xen/ +6 more | +146 | 10 replies | |
| 6/7 | Add verbatim copy of arm-smmu-v3.c from Linuxxen/ | +2791 | 0 replies | |
| 7/7 | xen/iommu: smmu-v3: Add Xen specific code to enable the ported driverxen/ xen/ | +738 | 8 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [RFC v2 0/7] SMMUv3 driver and the supporting framework
This change incoporates most of the review comments from [1] and adds the proposed SMMUv3 driver.
List of changes:
- Introduce the iommu_fwspec implementation - No change from the last RFC
- IORT port from linux. The differences are as under:
* Modified the code for creating the SMMU devices. This code also initializes the discoverd SMMU devices.
* MSI code is left as is, but this code is untested.
* IORT node data parsing is delegated to the driver. Looking for comments
on enabling the code in IORT driver. This will need a standard resource object. (Direct port from Linux or a new define for Xen?)
* Assumptions on PCI IORT SMMU interaction. PCI assign device will call iort_iommu_configure to setup the streamids.Then it will call SMMU assign device with the right struct device argument.
- SMMUv3 port from Linux. The list of changes are as under:
* The Xen iommu_ops list is at parity with SMMUv2.
* There is generally no need for an IOMMU group, but have kept a dummy define for now.
* Have commented out the S1 translation code.
* MSI code is commented out.
* Page table ops are commented out as the driver shares the page tables with the cpu.
* The list of SMMU devices is maintained from the driver code.
Open questions:
- IORT regeneration for DOM0. I was hoping to get some update on [2].
- We also need a notification framework to get the Named node information from DSDT.
- Should we port over code for non-hsared page tables from the kernel or leverage [3].
[1] "[RFC 0/6] IORT support and introduce fwspec"
[2] "[Xen-devel] [RFC] [PATCH] arm-acpi: Hide SMMU from IORT for hardware domain"
[3] "Non-shared" IOMMU support on ARM"
Sameer Goel (7):
passthrough/arm: Modify SMMU driver to use generic device definition
arm64: Add definitions for fwnode_handle xen/passthrough/arm: Introduce iommu_fwspec
ACPI: arm: Support for IORT
acpi:arm64: Add support for parsing IORT table
Add verbatim copy of arm-smmu-v3.c from Linux
xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver
xen/arch/arm/setup.c | 3 + xen/drivers/acpi/Makefile | 1 + xen/drivers/acpi/arm/Makefile | 1 + xen/drivers/acpi/arm/iort.c | 986 ++++++++++ xen/drivers/passthrough/arm/Makefile | 1 + xen/drivers/passthrough/arm/iommu.c | 66 + xen/drivers/passthrough/arm/smmu-v3.c | 3412 +++++++++++++++++++++++++++++++++ xen/drivers/passthrough/arm/smmu.c | 13 +- xen/include/acpi/acpi_iort.h | 61 + xen/include/asm-arm/device.h | 5 + xen/include/xen/acpi.h | 21 + xen/include/xen/fwnode.h | 33 + xen/include/xen/iommu.h | 29 + xen/include/xen/pci.h | 8 + 14 files changed, 4634 insertions(+), 6 deletions(-) create mode 100644 xen/drivers/acpi/arm/Makefile create mode 100644 xen/drivers/acpi/arm/iort.c create mode 100644 xen/drivers/passthrough/arm/smmu-v3.c create mode 100644 xen/include/acpi/acpi_iort.h create mode 100644 xen/include/xen/fwnode.h
Signature · 7 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. _______________________________________________ Xen-devel mailing list [email protected] https://lists.xen.org/xen-devel