All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Will Deacon <will@kernel.org>
Cc: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>,
	"Joerg Roedel (AMD)" <joro@8bytes.org>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-arm-msm@vger.kernel.org, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Prakash Gupta <prakash.gupta@oss.qualcomm.com>
Subject: Re: [PATCH] iommu/io-pgtable-arm: Add support for contiguous hint bit
Date: Wed, 15 Jul 2026 09:28:30 -0300	[thread overview]
Message-ID: <20260715122830.GB3775915@nvidia.com> (raw)
In-Reply-To: <ald3CuddY6I7gml1@willie-the-truck>

On Wed, Jul 15, 2026 at 01:03:22PM +0100, Will Deacon wrote:

> From what I can tell, the fiddly parts for iommupt will be:
> 
>   1. Hardware bugs / quirks. Some of the simpler ones could probably be
>      handled but for the more invasive stuff like the Mali format
>      format, io-pgtable will probably need to hang around. Perhaps
>      it becomes io-pgtable-mali.c?

I briefly looked at Mali a while back and it didn't seem so bad, but
that was for a GPU driver not the iommu so a bit different
issue. Exactly what the GPU drivers should be doing is less clear to
me, they don't really fit well with the iommu focused interface (eg
the memory preload issues/etc).

>   2. The pKVM work from Mostafa. We'll probably end up with something
>      separate at EL2 for this (ideally, just reusing the CPU page-table
>      code when it learns about BBML3).

Yeah, I'm not sure here, it isn't great that is adding another user
and open coding some of the logic (eg smmu_pgsize_idmap). It would be
much better if it could just use all the existing flow more directly
somehow.

>   3. Non-coherent walkers, although I think this might actually be fine
>      because x86 needs it anyway?

This is done already, the smmuv3 conversion I've posted supports it.

> So, for now, I wouldn't require new drivers to use iommupt but I'm

The recently posted broadcom driver used iommupt and I thought it
turned out very clean, it actually seems like less work to do it this
way than try to write your own page table like that rockchip driver
did which required several review rounds.

Jason

      parent reply	other threads:[~2026-07-15 12:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18  9:02 [PATCH] iommu/io-pgtable-arm: Add support for contiguous hint bit Vijayanand Jitta
2026-06-19 19:40 ` Daniel Mentz
2026-06-25  5:47   ` Vijayanand Jitta
2026-07-03 16:12 ` Jason Gunthorpe
2026-07-07 23:04   ` Daniel Mentz
2026-07-07 23:58     ` Jason Gunthorpe
2026-07-15  5:55   ` Vijayanand Jitta
2026-07-15 11:39     ` Jason Gunthorpe
2026-07-15 12:03       ` Will Deacon
2026-07-15 12:14         ` Robin Murphy
2026-07-15 12:50           ` Jason Gunthorpe
2026-07-15 17:45             ` Robin Murphy
2026-07-15 18:09               ` Jason Gunthorpe
2026-07-15 12:28         ` Jason Gunthorpe [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260715122830.GB3775915@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prakash.gupta@oss.qualcomm.com \
    --cc=robin.murphy@arm.com \
    --cc=vijayanand.jitta@oss.qualcomm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.