Generic IOMMU page table framework

This is version two of the patch series I originally posted here:

v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/306786.html

Changes since v1 include:

- Separated 32-bit and 64-bit regimes
- Limited pgd allocation when a full page is not required
- Addition of NS quirk, needed by Laurent for the Renesas IOMMU
- Added kerneldoc for the API to IOMMU drivers
- A few minor changes after feedback on the list

All feedback welcome,

--->8

Laurent Pinchart (1):
iommu: io-pgtable-arm: add non-secure quirk

Will Deacon (4):
iommu: introduce generic page table allocation framework
iommu: add ARM LPAE page table allocator
iommu: add self-consistency tests to ARM LPAE IO page table allocator iommu/arm-smmu: make use of generic LPAE allocator

 MAINTAINERS                    |   1 +
 arch/arm64/Kconfig             |   1 -
 drivers/iommu/Kconfig          |  32 +-
 drivers/iommu/Makefile         |   2 +
 drivers/iommu/arm-smmu.c       | 886 +++++++++++-------------------------
 drivers/iommu/io-pgtable-arm.c | 986 +++++++++++++++++++++++++++++++++++++++++
 drivers/iommu/io-pgtable.c     |  82 ++++
 drivers/iommu/io-pgtable.h     | 143 ++++++
 8 files changed, 1506 insertions(+), 627 deletions(-)
 create mode 100644 drivers/iommu/io-pgtable-arm.c
 create mode 100644 drivers/iommu/io-pgtable.c
 create mode 100644 drivers/iommu/io-pgtable.h

Signature · 1 line

2.1.4

I've not received any feedback on this revision of the series, but it's working well for me and Laurent showed that it works with his IOMMU too.

Joerg -- can I include this in my pull request for 3.20, or is there anything further you'd like me to address? The code is completely self-contained, so I wouldn't expect any impact on IOMMU drivers that don't explicitly use the new page table API.

Quoted 7 lines · Will Deacon

I've not received any feedback on this revision of the series, but it's working well for me and Laurent showed that it works with his IOMMU too.

Joerg -- can I include this in my pull request for 3.20, or is there anything further you'd like me to address? The code is completely self-contained, so I wouldn't expect any impact on IOMMU drivers that don't explicitly use the new page table API.

The patch-set looks good to me. But with code generification in general, what are the plans for other arm iommu drivers to adopt this?

Quoted 9 lines · On Mon, Jan 19, 2015 at 01:09:41PM +0000, joro at 8bytes.org wrote:

Quoted 7 lines · Will Deacon

I've not received any feedback on this revision of the series, but it's working well for me and Laurent showed that it works with his IOMMU too.

Joerg -- can I include this in my pull request for 3.20, or is there anything further you'd like me to address? The code is completely self-contained, so I wouldn't expect any impact on IOMMU drivers that don't explicitly use the new page table API.

Quoted 2 lines

The patch-set looks good to me. But with code generification in general, what are the plans for other arm iommu drivers to adopt this?

I think Laurent was going to make use of it and I'm working on a driver that will use it too.

Laurent -- you had patches ready to go for v1, right?

Yes, and I've rebased them (or actually it, it's a single patch) on v2. I haven't had time to test the result yet, I'll try to do so later tonight or tomorrow.

Replace the custom page table allocation implementation with the standard allocator.

The driver loses the ability to map 64kB chunkgs using the PTE contiguous hint, hence the removal of the SZ_64K page size from the IOMMU page sizes bitmap.

Signed-off-by Laurent Pinchart <[email protected]>

---
 drivers/iommu/Kconfig      |   1 +
 drivers/iommu/ipmmu-vmsa.c | 554 +++++----------------------------------------
 2 files changed, 61 insertions(+), 494 deletions(-)

This patch depends on Will Deacon's "[PATCH v2 0/5] Generic IOMMU page table framework" series.

Joerg, if you want to merge Will's patches in v3.20 with one user, this is a good candidate.

Changes since v1:

- Rebased on top of latest page table framework and iommu next branch.

Quoted 21 lines · Laurent Pinchart

Replace the custom page table allocation implementation with the standard allocator.

The driver loses the ability to map 64kB chunkgs using the PTE contiguous hint, hence the removal of the SZ_64K page size from the IOMMU page sizes bitmap.

Signed-off-by: Laurent Pinchart
<[email protected]>
---

 drivers/iommu/Kconfig      |   1 +
 drivers/iommu/ipmmu-vmsa.c | 554 ++++------------------------------------
 2 files changed, 61 insertions(+), 494 deletions(-)

This patch depends on Will Deacon's "[PATCH v2 0/5] Generic IOMMU page table framework" series.

Joerg, if you want to merge Will's patches in v3.20 with one user, this is a good candidate.

Quoted 3 lines

Changes since v1:

- Rebased on top of latest page table framework and iommu next branch.

Laurent, this is really good stuff, thanks!

Shall I queue this on top of the iommu/pgtbl patches, or do you have other ipmmu patches queued?

All my other ipmmu patches have been queued by Joerg in his next branch, on which this patch is based. If you base your series on the same branch you can just queue this patch on top of it. Do you plan to submit the result to v3.20 or v3.21 ?

Quoted 4 lines · Laurent Pinchart

All my other ipmmu patches have been queued by Joerg in his next branch, on which this patch is based. If you base your series on the same branch you can just queue this patch on top of it. Do you plan to submit the result to v3.20 or v3.21 ?

Hmm, I would prefer to not merge stuff together like this. Preferably I would like to put the generic page-table patches for ARM in a seperate topic-branch without any other changes merged in, given that this does not cause any non-trivial merge conflicts in the end for my next branch.

As you wish. I just thought you would prefer merging the series with at least one user.

Quoted 2 lines · Laurent Pinchart

As you wish. I just thought you would prefer merging the series with at least one user.

Yes, and with your patch there would be two users: ARM-SMMU and the VMSA IPMMU. So ideally I would apply/pull Will's patches on v3.19-rc5 with your patch on-top (and no other patches as dependency).

Quoted 7 lines · On Wednesday 21 January 2015 16:27:24 joro at 8bytes.org wrote:

Quoted 2 lines · Laurent Pinchart

As you wish. I just thought you would prefer merging the series with at least one user.

Yes, and with your patch there would be two users: ARM-SMMU and the VMSA IPMMU. So ideally I would apply/pull Will's patches on v3.19-rc5 with your patch on-top (and no other patches as dependency).

But that would conflict with the IPMMU patches that you have already queued for v3.20.