[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250709185411.GJ1599700@nvidia.com>
Date: Wed, 9 Jul 2025 15:54:11 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Jacob Pan <jacob.pan@...ux.microsoft.com>
Cc: Dave Hansen <dave.hansen@...el.com>,
Lu Baolu <baolu.lu@...ux.intel.com>, Joerg Roedel <joro@...tes.org>,
Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
Kevin Tian <kevin.tian@...el.com>, Jann Horn <jannh@...gle.com>,
Vasant Hegde <vasant.hegde@....com>,
Alistair Popple <apopple@...dia.com>,
Peter Zijlstra <peterz@...radead.org>,
Uladzislau Rezki <urezki@...il.com>,
Jean-Philippe Brucker <jean-philippe@...aro.org>,
Andy Lutomirski <luto@...nel.org>, iommu@...ts.linux.dev,
security@...nel.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH 1/1] iommu/sva: Invalidate KVA range on kernel TLB flush
On Wed, Jul 09, 2025 at 11:44:32AM -0700, Jacob Pan wrote:
> So you are saying IOMMU can cache user DMA initiated walks and cache
> with supervisor privilige? Since the SVA PASID is a user PASID, even if
> IOMMU uses the cache later on, how could it get supervior privilege?
The walk cache (aka paging structure cache) and IOTLB cache are
different things.
The walk cache has no concept of privilege. All memory holding page
tables can be loaded into the walk cache. Meaning any table in the
radix tree is eligible to reside in the walk cache.
So we point the IOMMU at the CR3 of a MM struct with KVA's mapped into
it and the walk cache is permitted to somehow cache every single 4k
page that comprises that radix tree.
Supervisor does not come into it at all. I had hoped the U/S bits
within the table structure itself would effect the walk cache but it
was confirmed that it does not.
Jason
Powered by blists - more mailing lists