| Message ID | 20200430143424.2787566-1-jean-philippe@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | iommu: Shared Virtual Addressing for SMMUv3 | expand |
On Thu, 30 Apr 2020 16:33:59 +0200 Jean-Philippe Brucker <jean-philippe@linaro.org> wrote: > Shared Virtual Addressing (SVA) allows to share process page tables > with devices using the IOMMU, PASIDs and I/O page faults. Add SVA > support to the Arm SMMUv3 driver. > > Since v5 [1]: > > * Added patches 1-3. Patch 1 adds a PASID field to mm_struct as > discussed in [1] and [2]. This is also needed for Intel ENQCMD. > Patch 2 adds refcounts to IOASID and patch 3 adds a couple of helpers > to allocate the PASID. > > * Dropped most of iommu-sva.c. After getting rid of io_mm following > review of v5, there wasn't enough generic code left to justify the > indirect branch overhead of io_mm_ops in the MMU notifiers. I ended > up with more glue than useful code, and couldn't find an easy way to > deal with domains in the SMMU driver (we keep PASID tables per domain, > while x86 keeps them per device). The direct approach in patch 17 is > nicer and a little easier to read. The SMMU driver only gained 160 > lines, while iommu-sva lost 470 lines. > > As a result I dropped the MMU notifier patch. > > Jacob, one upside of this rework is that we now free ioasids in > blocking context, which might help with your addition of notifiers > to ioasid.c > Thanks for the note. It does make notifier much easier, plus the refcount can alleviate the constraint on ordering. I guess we don't share mmu notifier code for now :) > * Simplified io-pgfault a bit, since flush() isn't called from mm exit > path anymore. > > * Fixed a bug in patch 17 (don't clear the stall bit when stall is > forced). > > You can find the latest version on https://jpbrucker.net/git/linux > branch sva/current, and sva/zip-devel for the Hisilicon zip > accelerator. > > [1] > https://lore.kernel.org/linux-iommu/20200414170252.714402-1-jean-philippe@linaro.org/ > [2] > https://lore.kernel.org/linux-iommu/1585596788-193989-6-git-send-email-fenghua.yu@intel.com/ > > Jean-Philippe Brucker (25): > mm: Add a PASID field to mm_struct > iommu/ioasid: Add ioasid references > iommu/sva: Add PASID helpers > iommu: Add a page fault handler > iommu/iopf: Handle mm faults > arm64: mm: Add asid_gen_match() helper > arm64: mm: Pin down ASIDs for sharing mm with devices > iommu/io-pgtable-arm: Move some definitions to a header > iommu/arm-smmu-v3: Manage ASIDs with xarray > 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: Add support for VHE > iommu/arm-smmu-v3: Enable broadcast TLB maintenance > iommu/arm-smmu-v3: Add SVA feature checking > 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 > iommu/arm-smmu-v3: Add support for Hardware Translation Table Update > iommu/arm-smmu-v3: Maintain a SID->device structure > dt-bindings: document stall property for IOMMU masters > iommu/arm-smmu-v3: Add stall support for platform devices > PCI/ATS: Add PRI stubs > PCI/ATS: Export PRI functions > iommu/arm-smmu-v3: Add support for PRI > > drivers/iommu/Kconfig | 11 + > drivers/iommu/Makefile | 2 + > .../devicetree/bindings/iommu/iommu.txt | 18 + > 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.h | 15 + > include/linux/ioasid.h | 10 +- > include/linux/iommu.h | 53 + > include/linux/mm_types.h | 4 + > include/linux/pci-ats.h | 8 + > arch/arm64/kernel/cpufeature.c | 1 + > arch/arm64/mm/context.c | 103 +- > drivers/iommu/arm-smmu-v3.c | 1554 > +++++++++++++++-- drivers/iommu/io-pgfault.c | > 458 +++++ drivers/iommu/io-pgtable-arm.c | 27 +- > drivers/iommu/ioasid.c | 30 +- > drivers/iommu/iommu-sva.c | 85 + > drivers/iommu/of_iommu.c | 5 +- > drivers/pci/ats.c | 4 + > MAINTAINERS | 3 +- > 21 files changed, 2275 insertions(+), 158 deletions(-) > create mode 100644 drivers/iommu/io-pgtable-arm.h > create mode 100644 drivers/iommu/iommu-sva.h > create mode 100644 drivers/iommu/io-pgfault.c > create mode 100644 drivers/iommu/iommu-sva.c > [Jacob Pan]
On Thu, Apr 30, 2020 at 02:18:16PM -0700, Jacob Pan wrote: > On Thu, 30 Apr 2020 16:33:59 +0200 > Jean-Philippe Brucker <jean-philippe@linaro.org> wrote: > > > Shared Virtual Addressing (SVA) allows to share process page tables > > with devices using the IOMMU, PASIDs and I/O page faults. Add SVA > > support to the Arm SMMUv3 driver. > > > > Since v5 [1]: > > > > * Added patches 1-3. Patch 1 adds a PASID field to mm_struct as > > discussed in [1] and [2]. This is also needed for Intel ENQCMD. > > Patch 2 adds refcounts to IOASID and patch 3 adds a couple of helpers > > to allocate the PASID. > > > > * Dropped most of iommu-sva.c. After getting rid of io_mm following > > review of v5, there wasn't enough generic code left to justify the > > indirect branch overhead of io_mm_ops in the MMU notifiers. I ended > > up with more glue than useful code, and couldn't find an easy way to > > deal with domains in the SMMU driver (we keep PASID tables per domain, > > while x86 keeps them per device). The direct approach in patch 17 is > > nicer and a little easier to read. The SMMU driver only gained 160 > > lines, while iommu-sva lost 470 lines. > > > > As a result I dropped the MMU notifier patch. > > > > Jacob, one upside of this rework is that we now free ioasids in > > blocking context, which might help with your addition of notifiers > > to ioasid.c > > > Thanks for the note. It does make notifier much easier, plus the > refcount can alleviate the constraint on ordering. > > I guess we don't share mmu notifier code for now :) I think it's more efficient for each IOMMU driver to at least implement their own invalidate_range() callback and avoid indirect branches. For the rest I couldn't find a lot of code to share, most of it is writing PASID tables and invalidating. We can revisit later, as long as we agree on the bind() API the implementations should be similar enough. Thanks, Jean