From: Lu Baolu <baolu.lu@linux.intel.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH 1/5] iommu/vt-d: Restore WO permissions on second-level paging entries
Date: Tue, 13 May 2025 11:07:35 +0800 [thread overview]
Message-ID: <20250513030739.2718555-2-baolu.lu@linux.intel.com> (raw)
In-Reply-To: <20250513030739.2718555-1-baolu.lu@linux.intel.com>
From: Jason Gunthorpe <jgg@nvidia.com>
VT-D HW can do WO permissions on the second-stage but not the first-stage
page table formats. The commit eea53c581688 ("iommu/vt-d: Remove WO
permissions on second-level paging entries") wanted to make this uniform
for VT-D by disabling the support for WO permissions in the second-stage.
This isn't consistent with how other drivers are working. Instead if the
underlying HW can support WO, it should. For instance AMD already supports
WO on its second stage (v1) format and not its first (v2).
If WO support needs to be discoverable it should be done through an
iommu_domain capability flag.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Link: https://lore.kernel.org/r/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
---
drivers/iommu/intel/iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index cb0b993bebb4..67c6ea1d8d44 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -1681,9 +1681,8 @@ __domain_mapping(struct dmar_domain *domain, unsigned long iov_pfn,
}
attr = prot & (DMA_PTE_READ | DMA_PTE_WRITE | DMA_PTE_SNP);
- attr |= DMA_FL_PTE_PRESENT;
if (domain->use_first_level) {
- attr |= DMA_FL_PTE_US | DMA_FL_PTE_ACCESS;
+ attr |= DMA_FL_PTE_PRESENT | DMA_FL_PTE_US | DMA_FL_PTE_ACCESS;
if (prot & DMA_PTE_WRITE)
attr |= DMA_FL_PTE_DIRTY;
}
--
2.43.0
next prev parent reply other threads:[~2025-05-13 3:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-13 3:07 [PATCH 0/5] [PULL REQUEST] Intel IOMMU updates for v6.16 Lu Baolu
2025-05-13 3:07 ` Lu Baolu [this message]
2025-05-13 3:07 ` [PATCH 2/5] iommu/vt-d: Use ida to manage domain id Lu Baolu
2025-05-13 3:07 ` [PATCH 3/5] iommu/vt-d: Replace spin_lock with mutex to protect domain ida Lu Baolu
2025-05-13 3:07 ` [PATCH 4/5] iommu/vt-d: Eliminate pci_physfn() in dmar_find_matched_satc_unit() Lu Baolu
2025-05-13 3:07 ` [PATCH 5/5] iommu/vt-d: Change dmar_ats_supported() to return boolean Lu Baolu
2025-05-16 6:49 ` [PATCH 0/5] [PULL REQUEST] Intel IOMMU updates for v6.16 Joerg Roedel
-- strict thread matches above, loose matches on Subject: below --
2025-05-14 5:52 [PATCH 1/5] iommu/vt-d: Restore WO permissions on second-level paging entries Aditya Garg
2025-05-14 6:39 ` Baolu Lu
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=20250513030739.2718555-2-baolu.lu@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.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