All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Mostafa Saleh <smostafa@google.com>
Cc: Will Deacon <will@kernel.org>,
	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: Sat, 18 Jul 2026 20:09:17 -0300	[thread overview]
Message-ID: <20260718230917.GG699082@nvidia.com> (raw)
In-Reply-To: <alvd9zPeXQVQ7l2l@google.com>

On Sat, Jul 18, 2026 at 08:11:35PM +0000, Mostafa Saleh wrote:
> On Wed, Jul 15, 2026 at 09:28:30AM -0300, Jason Gunthorpe wrote:
> > 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.
> 
> I was under the impression that io-pgtable-arm will remain the same,
> but if it is going to be removed (or at least the LPAE format) I need
> to figure out an alternative for pKVM:

I wasn't going to suggest you change anything with your series at this
point, just opining it is "not great", but I wouldn't object to
merging it as you've constructed it right now.

> - Compile iommupt for the hypervisor (similar to what we do with
>   io-pgtable-arm in the SMMUv3 pKVM series which compiles in both)
>   I am not sure how easy is that for iommupt, I have the SMMUv3
>   iommupt series on my review list, I will check that.

It is probably similarish, I thought your new version was pretty clean
when I glanced at it.

> - Write a small IO page table implementation just for the hypervisor,
>   that's not ideal as it would benefit also from features as CONTPTE.
 
You can do this pretty easially with the generic_pt and you can write
the thing exactly as you need. I wouldn't do this unless there was a
big mismatch with what iommu_domain provides.

Jason


      reply	other threads:[~2026-07-18 23:09 UTC|newest]

Thread overview: 17+ 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-16 11:59                 ` Robin Murphy
2026-07-15 12:28         ` Jason Gunthorpe
2026-07-18 20:11           ` Mostafa Saleh
2026-07-18 23:09             ` 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=20260718230917.GG699082@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=smostafa@google.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.