From: Jason Gunthorpe <jgg@nvidia.com>
To: Alexey Kardashevskiy <aik@amd.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>, Anup Patel <anup@brainfault.org>,
Albert Ou <aou@eecs.berkeley.edu>,
Jonathan Corbet <corbet@lwn.net>,
iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
Justin Stitt <justinstitt@google.com>,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-riscv@lists.infradead.org, llvm@lists.linux.dev,
Bill Wendling <morbo@google.com>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Miguel Ojeda <ojeda@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <pjw@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Shuah Khan <shuah@kernel.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Will Deacon <will@kernel.org>,
Alejandro Jimenez <alejandro.j.jimenez@oracle.com>,
James Gowans <jgowans@amazon.com>,
Kevin Tian <kevin.tian@intel.com>,
Michael Roth <michael.roth@amd.com>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
patches@lists.linux.dev, Samiullah Khawaja <skhawaja@google.com>,
Vasant Hegde <vasant.hegde@amd.com>
Subject: Re: [PATCH v8 07/15] iommupt: Add map_pages op
Date: Thu, 22 Jan 2026 10:12:40 -0400 [thread overview]
Message-ID: <20260122141240.GM1134360@nvidia.com> (raw)
In-Reply-To: <5a3dfc0a-eca4-4de1-96cd-b4034f0b8e06@amd.com>
On Thu, Jan 22, 2026 at 09:58:04PM +1100, Alexey Kardashevskiy wrote:
> > This issue with the RMP is no different, if you get a 2M IOPTE then
> > the HW should check the RMP and load in a 4K IOPTE to the IOTLB if
> > that is what the RMP requires.
> > That the HW doesn't do that means you have all these difficult
> > problems.
>
> Got it. Interestingly the HW actually does that, almost. Say, for
> >=2MB IO pages it checks if RMP==2MB and puts a 2MB IO TLB entry if
> RMP==2MB, and for 4KB..1MB IO pages - a 4K IO TLB entry and RMP==4K
> check. But it does not cross the 2MB boundary in RMP. Uff :-/
Not sure I understand this limitation, how does any aligned size cross
a 2MB boundary?
Sounds like it was thought about, is it a HW bug some cases don't
work?
> on the other hand, without swiotlb, dma_map() in the guest for
> untrusted device is likely to be lot less than 2MB and going to
> share another handful of pages but this activity is not that rare
> compared to my certificates example. If only there was a way to
> somehow bundle such allocations/mappings... :-/
ARM is pushing a thing where encrypt/decrypt has to work on certain aligned
granual sizes > PAGE_SIZE, you could use that mechanism to select a 2M
size for AMD too and avoid this.
> > That's a completely grotesque solution!
> >
> > It violates all of our software layers. The IOMMU and RMP are not
> > controled by the same software entity and you propose to have a FW
> > call that edits *both* together somehow? How is that even going to
> > work safely?
> >
> > Can't you do things in a sequence?
> >
> > Change the iommu from 2M to 4K, flush, then change the RMP from 2M to
> > 4K?
>
> Sure we could unless there is ongoing DMA between "flush" and "then
> change" and then DMA will fail because of mismatching page sizes
> (that 2MB crossing thing above).
I'm confused, if the IOMMU has 4K and the RMP has 2M it doesn't work?
Then why was I told the 4k page size kernel parameter fixes
everything?
What happens if the guest puts 4K pages into it's AMDv2 table and RMP
is 2M?
> > > If I get it right, for other platforms, the entire IOMMU table is
> > > going to live in a secure space so there will be similar FW calls so
> > > it is not that different.
> >
> > At least ARM the iommu S2 table is in secure memory and the secure FW
> > keeps it 1:1 with the KVM S2 table. So edits to the KVM automatically
> > make matching edits to the IOMMU. Only one software layer is
> > responsible for things.
?
> Does KVM talk to the host IOMMU code for that (and then the IOMMU code calls the secure world)?
> Or KVM goes straight to that secure world?
Straight to the secure world, there is no host IOMMU driver for the
secure IOMMU.
> Is the host IOMMU code aware of the content of the secure IOMMU table?
No, it isn't even aware it exist.
> Does 2MB->4K smashing exist on ARM at all?
Every arch has cases where larger mappings need to be reduced to
smaller ones, but ARM doesn't require synchronized coordination
between multiple tables.
Jason
next prev parent reply other threads:[~2026-01-22 14:12 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-04 18:29 [PATCH v8 00/15] Consolidate iommu page table implementations (AMD) Jason Gunthorpe
2025-11-04 18:29 ` [PATCH v8 01/15] genpt: Generic Page Table base API Jason Gunthorpe
2025-11-04 18:30 ` [PATCH v8 02/15] genpt: Add Documentation/ files Jason Gunthorpe
2025-11-04 23:49 ` Randy Dunlap
2025-11-05 18:51 ` Jason Gunthorpe
2025-11-04 18:30 ` [PATCH v8 03/15] iommupt: Add the basic structure of the iommu implementation Jason Gunthorpe
2025-11-04 18:30 ` [PATCH v8 04/15] iommupt: Add the AMD IOMMU v1 page table format Jason Gunthorpe
2025-11-04 18:51 ` Randy Dunlap
2025-11-04 18:30 ` [PATCH v8 05/15] iommupt: Add iova_to_phys op Jason Gunthorpe
2025-11-04 19:02 ` Randy Dunlap
2025-11-04 19:19 ` Jason Gunthorpe
2025-11-04 18:30 ` [PATCH v8 06/15] iommupt: Add unmap_pages op Jason Gunthorpe
2025-11-04 18:30 ` [PATCH v8 07/15] iommupt: Add map_pages op Jason Gunthorpe
2026-01-17 4:54 ` Alexey Kardashevskiy
2026-01-17 15:43 ` Jason Gunthorpe
2026-01-19 1:00 ` Alexey Kardashevskiy
2026-01-19 17:37 ` Jason Gunthorpe
2026-01-21 1:08 ` Alexey Kardashevskiy
2026-01-21 17:09 ` Jason Gunthorpe
2026-01-22 10:58 ` Alexey Kardashevskiy
2026-01-22 14:12 ` Jason Gunthorpe [this message]
2026-01-23 1:07 ` Alexey Kardashevskiy
2026-01-23 14:14 ` Jason Gunthorpe
2026-01-27 8:08 ` Alexey Kardashevskiy
2026-01-27 14:25 ` Jason Gunthorpe
2026-01-28 1:42 ` Alexey Kardashevskiy
2026-01-28 13:32 ` Jason Gunthorpe
2026-01-29 0:33 ` Alexey Kardashevskiy
2026-01-29 1:17 ` Jason Gunthorpe
2026-02-25 23:11 ` Alexey Kardashevskiy
2026-02-26 15:04 ` Jason Gunthorpe
2026-02-27 1:39 ` Alexey Kardashevskiy
2026-02-27 13:48 ` Jason Gunthorpe
2026-03-02 0:02 ` Alexey Kardashevskiy
2026-03-02 0:41 ` Jason Gunthorpe
2025-11-04 18:30 ` [PATCH v8 08/15] iommupt: Add read_and_clear_dirty op Jason Gunthorpe
2025-11-04 19:13 ` Randy Dunlap
2025-11-04 19:17 ` Jason Gunthorpe
2025-11-04 19:19 ` Randy Dunlap
2025-11-04 18:30 ` [PATCH v8 09/15] iommupt: Add a kunit test for Generic Page Table Jason Gunthorpe
2025-11-04 18:30 ` [PATCH v8 10/15] iommupt: Add a mock pagetable format for iommufd selftest to use Jason Gunthorpe
2025-11-04 18:30 ` [PATCH v8 11/15] iommufd: Change the selftest to use iommupt instead of xarray Jason Gunthorpe
2025-11-04 18:30 ` [PATCH v8 12/15] iommupt: Add the x86 64 bit page table format Jason Gunthorpe
2025-11-04 18:30 ` [PATCH v8 13/15] iommu/amd: Use the generic iommu page table Jason Gunthorpe
2025-11-05 16:01 ` Ankit Soni
2025-11-05 16:57 ` Jason Gunthorpe
2025-12-05 2:40 ` Lai, Yi
2025-12-05 19:46 ` Jason Gunthorpe
2025-12-05 20:07 ` Alejandro Jimenez
2025-11-04 18:30 ` [PATCH v8 14/15] iommu/amd: Remove AMD io_pgtable support Jason Gunthorpe
2025-11-04 18:30 ` [PATCH v8 15/15] iommupt: Add a kunit test for the IOMMU implementation Jason Gunthorpe
2025-11-05 8:45 ` [PATCH v8 00/15] Consolidate iommu page table implementations (AMD) Joerg Roedel
2025-11-05 12:43 ` Jason Gunthorpe
2025-12-19 8:10 ` patchwork-bot+linux-riscv
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=20260122141240.GM1134360@nvidia.com \
--to=jgg@nvidia.com \
--cc=aik@amd.com \
--cc=alejandro.j.jimenez@oracle.com \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=corbet@lwn.net \
--cc=iommu@lists.linux.dev \
--cc=jgowans@amazon.com \
--cc=joro@8bytes.org \
--cc=justinstitt@google.com \
--cc=kevin.tian@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=michael.roth@amd.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=ojeda@kernel.org \
--cc=palmer@dabbelt.com \
--cc=pasha.tatashin@soleen.com \
--cc=patches@lists.linux.dev \
--cc=pjw@kernel.org \
--cc=robin.murphy@arm.com \
--cc=shuah@kernel.org \
--cc=skhawaja@google.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=vasant.hegde@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox