[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB5276C686DB7BDD83FAA7FF548C8DA@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Fri, 16 Jan 2026 06:16:31 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: Baolu Lu <baolu.lu@...ux.intel.com>, Samiullah Khawaja
<skhawaja@...gle.com>, Joerg Roedel <joro@...tes.org>, Will Deacon
<will@...nel.org>, Robin Murphy <robin.murphy@....com>, Dmytro Maluka
<dmaluka@...omium.org>, "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 3/3] iommu/vt-d: Rework hitless PASID entry replacement
> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Thursday, January 15, 2026 9:28 PM
>
> On Thu, Jan 15, 2026 at 05:44:08AM +0000, Tian, Kevin wrote:
>
> > or in Samiullah's case the old/new domains always contains the
> > same mappings, so no corruption would ever occur, but that'd be
> > a very KHO specific assumption. 😊
>
> The thing witih KHO is we don't actually know this is true. We hope it
> is true, but ultimately userspace is responsible to do it, and the
> kernel doesn't check it.
Make sense.
Then the option having the new domain adopt the original ID could not
work either. We cannot have one DID tagging two domains which may
contain different mappings.
>
> This is why the hitless update in an appealing solution because it
> means we don't need to deal with trying to adopt an entire page table
> prepared by another kernel and ensuring this kernel has IOAS areas
> that fully cover and exactly match what is in the table.
>
> Unfortunately to do the extra DID will require a complex invalidation
> sequence to hook multiple DIDs into the same domain
> simultaneously.. Nicolin is working on this for ARM and I think
> Intel's linked list scheme could be tasked to do it too..
>
yes
Powered by blists - more mailing lists