All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Samiullah Khawaja <skhawaja@google.com>
Cc: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Dmytro Maluka <dmaluka@chromium.org>,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] iommu/vt-d: Rework hitless PASID entry replacement
Date: Wed, 14 Jan 2026 13:45:16 +0800	[thread overview]
Message-ID: <ef58cd8a-504d-457b-b731-f7dfdba0e43c@linux.intel.com> (raw)
In-Reply-To: <CAAywjhSv56Y9rJLVdqV9N54c7S30ZUjyNh05xc-EW2+dS74GFQ@mail.gmail.com>

On 1/14/26 03:27, Samiullah Khawaja wrote:
> On Mon, Jan 12, 2026 at 7:03 PM Lu Baolu<baolu.lu@linux.intel.com> wrote:
>> The Intel VT-d PASID table entry is 512 bits (64 bytes). Because the
>> hardware may fetch this entry in multiple 128-bit chunks, updating the
>> entire entry while it is active (P=1) risks a "torn" read where the
>> hardware observes an inconsistent state.
>>
>> However, certain updates (e.g., changing page table pointers while
>> keeping the translation type and domain ID the same) can be performed
>> hitlessly. This is possible if the update is limited to a single
>> 128-bit chunk while the other chunks remains stable.
>>
>> Introduce a hitless replacement mechanism for PASID entries:
>>
>> - Update 'struct pasid_entry' with a union to support 128-bit
>>    access via the newly added val128[4] array.
>> - Add pasid_support_hitless_replace() to determine if a transition
>>    between an old and new entry is safe to perform atomically.
>>    - For First-level/Nested translations: The first 128 bits (chunk 0)
>>      must remain identical; chunk 1 is updated atomically.
> Looking at the specs, the DID is part of the first 128 bits (chunk 0),
> so I guess for the first level the hitless replacement would not be
> supported since each domain will have a different DID?

It's not necessarily true that each domain will have a different DID. On
Intel IOMMU, all SVA domains can share a single DID. Similarly, multiple
nested domains sitting on top of the same second-stage page table can
also share a DID.

Thanks,
baolu

  parent reply	other threads:[~2026-01-14  5:45 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-13  3:00 [PATCH 0/3] iommu/vt-d: Ensure atomicity in context and PASID entry updates Lu Baolu
2026-01-13  3:00 ` [PATCH 1/3] iommu/vt-d: Use 128-bit atomic updates for context entries Lu Baolu
2026-01-13 19:27   ` Dmytro Maluka
2026-01-14  5:14     ` Baolu Lu
2026-01-14 10:55       ` Dmytro Maluka
2026-01-15  2:26         ` Baolu Lu
2026-01-15 13:12           ` Jason Gunthorpe
2026-01-14  7:54   ` Tian, Kevin
2026-01-15  3:26     ` Baolu Lu
2026-01-15  5:59       ` Tian, Kevin
2026-01-15 13:23         ` Jason Gunthorpe
2026-01-16  5:19           ` Tian, Kevin
2026-01-16 14:33             ` Jason Gunthorpe
2026-01-13  3:00 ` [PATCH 2/3] iommu/vt-d: Clear Present bit before tearing down PASID entry Lu Baolu
2026-01-13 19:34   ` Dmytro Maluka
2026-01-14  5:38     ` Baolu Lu
2026-01-14 11:12       ` Dmytro Maluka
2026-01-15  2:45         ` Baolu Lu
2026-01-15 21:35           ` Dmytro Maluka
2026-01-16  6:06             ` Baolu Lu
2026-01-20 13:49               ` Dmytro Maluka
2026-01-14  7:32   ` Tian, Kevin
2026-01-14  8:27     ` Baolu Lu
2026-01-15  5:49       ` Tian, Kevin
2026-01-13  3:00 ` [PATCH 3/3] iommu/vt-d: Rework hitless PASID entry replacement Lu Baolu
2026-01-13 15:05   ` Jason Gunthorpe
2026-01-14  6:03     ` Baolu Lu
2026-01-13 19:27   ` Samiullah Khawaja
2026-01-13 20:56     ` Jason Gunthorpe
2026-01-14  5:45     ` Baolu Lu [this message]
2026-01-14  7:26       ` Tian, Kevin
2026-01-14 13:17         ` Jason Gunthorpe
2026-01-14 18:51           ` Samiullah Khawaja
2026-01-14 19:07             ` Jason Gunthorpe
2026-01-15  5:44           ` Tian, Kevin
2026-01-15 13:28             ` Jason Gunthorpe
2026-01-16  6:16               ` Tian, Kevin
2026-01-13 19:39   ` Dmytro Maluka
2026-01-13 20:06     ` Dmytro Maluka

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=ef58cd8a-504d-457b-b731-f7dfdba0e43c@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=dmaluka@chromium.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=skhawaja@google.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.