| Message ID | 20200618155125.1548969-1-jean-philippe@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | iommu: Shared Virtual Addressing for SMMUv3 (PT sharing part) | expand |
Hi Will, On Thu, Jun 18, 2020 at 05:51:13PM +0200, Jean-Philippe Brucker wrote: > Since v7 [1], I split the series into three parts to ease review. This > first one adds page table sharing to the SMMUv3 driver. The second one > adds support for I/O page faults through PRI and Stall, and the last one > adds additional and optional features (DVM, VHE and HTTU). SVA needs the > three parts to work. No significant change apart from that, I just > addressed the previous comments. > > I'd rather everything went through the IOMMU tree but I'm assuming patch > 1 will also go through the x86 tree as part of [2]. It is definitely > required by patch 3 which is required by patch 11. I don't know how this > kind of conflict is usually resolved, but if it's a problem I could > further shrink the series to only patches 4-10 this cycle. I have one bugfix for this series but am planning to hold off resending until you've found time to have a look. I can also reduce it to 7 patches for v4.9, please let me know what you prefer. Thanks, Jean > > [1] https://lore.kernel.org/linux-iommu/20200519175502.2504091-1-jean-philippe@linaro.org/ > [2] https://lore.kernel.org/linux-iommu/1592418233-17762-1-git-send-email-fenghua.yu@intel.com/ > > Fenghua Yu (1): > mm: Define pasid in mm > > Jean-Philippe Brucker (11): > iommu/ioasid: Add ioasid references > iommu/sva: Add PASID helpers > arm64: mm: Pin down ASIDs for sharing mm with devices > iommu/io-pgtable-arm: Move some definitions to a header > arm64: cpufeature: Export symbol read_sanitised_ftr_reg() > iommu/arm-smmu-v3: Share process page tables > iommu/arm-smmu-v3: Seize private ASID > iommu/arm-smmu-v3: Check for SVA features > iommu/arm-smmu-v3: Add SVA device feature > iommu/arm-smmu-v3: Implement iommu_sva_bind/unbind() > iommu/arm-smmu-v3: Hook up ATC invalidation to mm ops > > drivers/iommu/Kconfig | 7 + > drivers/iommu/Makefile | 1 + > arch/arm64/include/asm/mmu.h | 1 + > arch/arm64/include/asm/mmu_context.h | 11 +- > drivers/iommu/io-pgtable-arm.h | 30 ++ > drivers/iommu/iommu-sva-lib.h | 15 + > include/linux/ioasid.h | 10 +- > include/linux/mm_types.h | 4 + > arch/arm64/kernel/cpufeature.c | 1 + > arch/arm64/mm/context.c | 95 +++- > drivers/iommu/arm-smmu-v3.c | 702 ++++++++++++++++++++++++++- > drivers/iommu/intel/iommu.c | 4 +- > drivers/iommu/intel/svm.c | 6 +- > drivers/iommu/io-pgtable-arm.c | 27 +- > drivers/iommu/ioasid.c | 38 +- > drivers/iommu/iommu-sva-lib.c | 85 ++++ > MAINTAINERS | 3 +- > 17 files changed, 977 insertions(+), 63 deletions(-) > create mode 100644 drivers/iommu/io-pgtable-arm.h > create mode 100644 drivers/iommu/iommu-sva-lib.h > create mode 100644 drivers/iommu/iommu-sva-lib.c > > -- > 2.27.0 >
On Thu, Jun 18, 2020 at 05:51:13PM +0200, Jean-Philippe Brucker wrote: > Since v7 [1], I split the series into three parts to ease review. This > first one adds page table sharing to the SMMUv3 driver. The second one > adds support for I/O page faults through PRI and Stall, and the last one > adds additional and optional features (DVM, VHE and HTTU). SVA needs the > three parts to work. No significant change apart from that, I just > addressed the previous comments. > > I'd rather everything went through the IOMMU tree but I'm assuming patch > 1 will also go through the x86 tree as part of [2]. It is definitely > required by patch 3 which is required by patch 11. I don't know how this > kind of conflict is usually resolved, but if it's a problem I could > further shrink the series to only patches 4-10 this cycle. Modulo my review comments, I think most of this looks alright from the SMMU side. However, I would really like it if the SVA driver parts could be moved into a separate file (e.g. arm-smmu-v3-sva.c), with a separate config option (dependent on the current one, so you can easily build a driver without SVA support). Does that sound remotely feasible? If so, I think it would really help in terms of maintainability, since the SVA model is really all about the mm, whereas the driver model is all about the device. This makes it really hard to read when you have to keep working out whether the current 'handle' is an mm_struct or an arm_smmu_device. Will
On Mon, Jul 20, 2020 at 12:11:17PM +0100, Will Deacon wrote: > On Thu, Jun 18, 2020 at 05:51:13PM +0200, Jean-Philippe Brucker wrote: > > Since v7 [1], I split the series into three parts to ease review. This > > first one adds page table sharing to the SMMUv3 driver. The second one > > adds support for I/O page faults through PRI and Stall, and the last one > > adds additional and optional features (DVM, VHE and HTTU). SVA needs the > > three parts to work. No significant change apart from that, I just > > addressed the previous comments. > > > > I'd rather everything went through the IOMMU tree but I'm assuming patch > > 1 will also go through the x86 tree as part of [2]. It is definitely > > required by patch 3 which is required by patch 11. I don't know how this > > kind of conflict is usually resolved, but if it's a problem I could > > further shrink the series to only patches 4-10 this cycle. > > Modulo my review comments, I think most of this looks alright from the SMMU > side. However, I would really like it if the SVA driver parts could be moved > into a separate file (e.g. arm-smmu-v3-sva.c), with a separate config option > (dependent on the current one, so you can easily build a driver without SVA > support). Does that sound remotely feasible? Yes it makes sense. It requires moving some definitions from arm-smmu-v3.c to a .h but should be straightforward, I'll give it a try. Thanks, Jean > If so, I think it would really > help in terms of maintainability, since the SVA model is really all about > the mm, whereas the driver model is all about the device. This makes it > really hard to read when you have to keep working out whether the current > 'handle' is an mm_struct or an arm_smmu_device. > > Will