From: Dan Williams <dan.j.williams@intel.com>
To: linux-coco@lists.linux.dev, linux-pci@vger.kernel.org
Cc: gregkh@linuxfoundation.org, aik@amd.com, aneesh.kumar@kernel.org,
yilun.xu@linux.intel.com, bhelgaas@google.com,
alistair23@gmail.com, lukas@wunner.de, jgg@nvidia.com,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: [PATCH v2 12/19] x86, ioremap, resource: Support IORES_DESC_ENCRYPTED for encrypted PCI MMIO
Date: Mon, 2 Mar 2026 16:02:00 -0800 [thread overview]
Message-ID: <20260303000207.1836586-13-dan.j.williams@intel.com> (raw)
In-Reply-To: <20260303000207.1836586-1-dan.j.williams@intel.com>
PCIe Trusted Execution Environment Device Interface Security Protocol
(TDISP) arranges for a PCI device to support encrypted MMIO. In support of
that capability, ioremap() needs a mechanism to detect when a PCI device
has been dynamically transitioned into this secure state and enforce
encrypted MMIO mappings.
Teach ioremap() about a new IORES_DESC_ENCRYPTED type that supplements the
existing PCI Memory Space (MMIO) BAR resources. The proposal is that a
resource, "PCI MMIO Encrypted", with this description type is injected by
the PCI/TSM core for each PCI device BAR that is to be protected.
Unlike the existing encryption determination which is "implied with a
silent fallback to an unencrypted mapping", this indication is "explicit
with an expectation that the request fails instead of fallback".
IORES_MUST_ENCRYPT is added to manage this expectation.
Given that "PCI MMIO Encrypted" is an additional resource in the tree, the
IORESOURCE_BUSY flag will only be set on a descendant/child of that
resource. That means it cannot share the same walk as the check for "System
RAM". Add walk_iomem_res_desc() to check if any IORES_DESC_ENCRYPTED
intersects the ioremap() range and set IORES_MUST_ENCRYPT accordingly. When
IORES_MUST_ENCRYPT is set, the entire ioremap() range must be covered by
IORES_DESC_ENCRYPTED.
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
include/linux/ioport.h | 1 +
arch/x86/mm/ioremap.c | 49 +++++++++++++++++++++++++++++++-----------
2 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 1c106608c514..3efd07443c47 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -152,6 +152,7 @@ enum {
enum {
IORES_MAP_SYSTEM_RAM = BIT(0),
IORES_MAP_ENCRYPTED = BIT(1),
+ IORES_MUST_ENCRYPT = BIT(2), /* disable transparent fallback */
};
/* helpers to define resources */
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 12c8180ca1ba..0f300e226a9f 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -36,6 +36,7 @@
*/
struct ioremap_desc {
unsigned int flags;
+ u64 encrypt_size;
};
/*
@@ -88,23 +89,35 @@ static unsigned int __ioremap_check_ram(struct resource *res)
}
/*
- * In a SEV guest, NONE and RESERVED should not be mapped encrypted because
- * there the whole memory is already encrypted.
+ * In a encrypted guest, NONE and RESERVED should not be mapped encrypted
+ * because there the whole memory is already encrypted.
+ *
+ * For the encrypted case the entire range must agree with being mapped
+ * encrypted.
*/
-static unsigned int __ioremap_check_encrypted(struct resource *res)
+static unsigned int __ioremap_check_encrypted(struct ioremap_desc *desc,
+ struct resource *res)
{
+ u32 flags = 0;
+
+ if (res->desc == IORES_DESC_ENCRYPTED)
+ flags |= IORES_MUST_ENCRYPT;
+
if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
- return 0;
+ return flags;
switch (res->desc) {
case IORES_DESC_NONE:
case IORES_DESC_RESERVED:
break;
+ case IORES_DESC_ENCRYPTED:
+ desc->encrypt_size += resource_size(res);
+ fallthrough;
default:
- return IORES_MAP_ENCRYPTED;
+ flags |= IORES_MAP_ENCRYPTED;
}
- return 0;
+ return flags;
}
/*
@@ -134,14 +147,10 @@ static int __ioremap_collect_map_flags(struct resource *res, void *arg)
{
struct ioremap_desc *desc = arg;
- if (!(desc->flags & IORES_MAP_SYSTEM_RAM))
- desc->flags |= __ioremap_check_ram(res);
-
- if (!(desc->flags & IORES_MAP_ENCRYPTED))
- desc->flags |= __ioremap_check_encrypted(res);
+ desc->flags |= __ioremap_check_ram(res);
+ desc->flags |= __ioremap_check_encrypted(desc, res);
- return ((desc->flags & (IORES_MAP_SYSTEM_RAM | IORES_MAP_ENCRYPTED)) ==
- (IORES_MAP_SYSTEM_RAM | IORES_MAP_ENCRYPTED));
+ return 0;
}
/*
@@ -162,6 +171,13 @@ static void __ioremap_check_mem(resource_size_t addr, unsigned long size,
memset(desc, 0, sizeof(struct ioremap_desc));
walk_mem_res(start, end, desc, __ioremap_collect_map_flags);
+ /*
+ * Encrypted MMIO may parent a driver's requested region, so it needs a
+ * separate search
+ */
+ desc->encrypt_size = 0;
+ walk_iomem_res_desc(IORES_DESC_ENCRYPTED, IORESOURCE_MEM, start, end,
+ desc, __ioremap_collect_map_flags);
__ioremap_check_other(addr, desc);
}
@@ -209,6 +225,13 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
__ioremap_check_mem(phys_addr, size, &io_desc);
+ if ((io_desc.flags & IORES_MUST_ENCRYPT) &&
+ io_desc.encrypt_size < size) {
+ pr_err("ioremap: encrypted mapping unavailable for %pa - %pa\n",
+ &phys_addr, &last_addr);
+ return NULL;
+ }
+
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
--
2.52.0
next prev parent reply other threads:[~2026-03-03 0:01 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 0:01 [PATCH v2 00/19] PCI/TSM: TEE I/O infrastructure Dan Williams
2026-03-03 0:01 ` [PATCH v2 01/19] PCI/TSM: Report active IDE streams per host bridge Dan Williams
2026-03-09 16:36 ` Jonathan Cameron
2026-03-03 0:01 ` [PATCH v2 02/19] device core: Fix kernel-doc warnings in base.h Dan Williams
2026-03-09 16:39 ` Jonathan Cameron
2026-03-12 14:45 ` Greg KH
2026-03-03 0:01 ` [PATCH v2 03/19] device core: Introduce confidential device acceptance Dan Williams
2026-03-09 16:42 ` Jonathan Cameron
2026-03-12 14:44 ` Greg KH
2026-03-13 4:11 ` Dan Williams
2026-03-13 12:18 ` Greg KH
2026-03-13 18:53 ` Dan Williams
2026-03-13 19:07 ` Jason Gunthorpe
2026-03-13 13:32 ` Jason Gunthorpe
2026-03-13 19:56 ` Dan Williams
2026-03-13 20:24 ` Jason Gunthorpe
2026-03-14 1:32 ` Dan Williams
2026-03-23 18:14 ` Jason Gunthorpe
2026-03-24 2:18 ` Dan Williams
2026-03-24 12:36 ` Jason Gunthorpe
2026-03-25 4:13 ` Dan Williams
2026-03-25 11:56 ` Jason Gunthorpe
2026-03-26 1:27 ` Dan Williams
2026-03-26 12:00 ` Jason Gunthorpe
2026-03-26 15:00 ` Greg KH
2026-03-26 18:31 ` Dan Williams
2026-03-26 19:28 ` Jason Gunthorpe
2026-03-03 0:01 ` [PATCH v2 04/19] modules: Document the global async_probe parameter Dan Williams
2026-03-03 0:01 ` [PATCH v2 05/19] device core: Autoprobe considered harmful? Dan Williams
2026-03-09 16:58 ` Jonathan Cameron
2026-03-03 0:01 ` [PATCH v2 06/19] PCI/TSM: Add Device Security (TVM Guest) LOCK operation support Dan Williams
2026-03-03 0:01 ` [PATCH v2 07/19] PCI/TSM: Add Device Security (TVM Guest) ACCEPT " Dan Williams
2026-03-03 7:15 ` Baolu Lu
2026-03-03 0:01 ` [PATCH v2 08/19] PCI/TSM: Add "evidence" support Dan Williams
2026-03-03 3:14 ` kernel test robot
2026-03-03 10:16 ` Aneesh Kumar K.V
2026-03-03 16:38 ` Aneesh Kumar K.V
2026-03-13 10:07 ` Xu Yilun
2026-03-13 18:06 ` Dan Williams
2026-03-14 18:12 ` Jakub Kicinski
2026-03-17 1:45 ` Dan Williams
2026-03-19 0:00 ` Jakub Kicinski
2026-03-20 2:50 ` Dan Williams
2026-03-17 18:14 ` Lukas Wunner
2026-03-18 7:56 ` Dan Williams
2026-03-23 18:18 ` Jason Gunthorpe
2026-03-14 18:37 ` Lukas Wunner
2026-03-16 20:13 ` Dan Williams
2026-03-16 23:02 ` Dan Williams
2026-03-17 14:13 ` Lukas Wunner
2026-03-18 7:22 ` Dan Williams
2026-03-17 18:24 ` Lukas Wunner
2026-03-18 7:41 ` Dan Williams
2026-03-03 0:01 ` [PATCH v2 09/19] PCI/TSM: Support creating encrypted MMIO descriptors via TDISP Report Dan Williams
2026-03-04 17:14 ` dan.j.williams
2026-03-13 9:57 ` Xu Yilun
2026-03-05 4:46 ` Aneesh Kumar K.V
2026-03-13 10:23 ` Xu Yilun
2026-03-13 13:36 ` Jason Gunthorpe
2026-03-17 5:13 ` Xu Yilun
2026-03-24 3:26 ` Dan Williams
2026-03-24 12:38 ` Jason Gunthorpe
2026-03-16 5:19 ` Alexey Kardashevskiy
2026-03-23 18:20 ` Jason Gunthorpe
2026-03-26 23:38 ` Alexey Kardashevskiy
2026-03-27 11:49 ` Jason Gunthorpe
2026-03-03 0:01 ` [PATCH v2 10/19] x86, swiotlb: Teach swiotlb to skip "accepted" devices Dan Williams
2026-03-03 9:07 ` Aneesh Kumar K.V
2026-03-13 10:26 ` Xu Yilun
2026-03-03 0:01 ` [PATCH v2 11/19] x86, dma: Allow accepted devices to map private memory Dan Williams
2026-03-03 7:36 ` Alexey Kardashevskiy
2026-03-03 0:02 ` Dan Williams [this message]
2026-03-19 15:34 ` [PATCH v2 12/19] x86, ioremap, resource: Support IORES_DESC_ENCRYPTED for encrypted PCI MMIO Borislav Petkov
2026-03-03 0:02 ` [PATCH v2 13/19] samples/devsec: Introduce a PCI device-security bus + endpoint sample Dan Williams
2026-03-03 0:02 ` [PATCH v2 14/19] samples/devsec: Add sample IDE establishment Dan Williams
2026-03-03 0:02 ` [PATCH v2 15/19] samples/devsec: Add sample TSM bind and guest_request flows Dan Williams
2026-03-03 0:02 ` [PATCH v2 16/19] samples/devsec: Introduce a "Device Security TSM" sample driver Dan Williams
2026-03-27 8:44 ` Lai, Yi
2026-03-03 0:02 ` [PATCH v2 17/19] tools/testing/devsec: Add a script to exercise samples/devsec/ Dan Williams
2026-03-03 0:02 ` [PATCH v2 18/19] samples/devsec: Add evidence support Dan Williams
2026-03-03 0:02 ` [PATCH v2 19/19] tools/testing/devsec: Add basic evidence retrieval validation Dan Williams
2026-03-03 9:23 ` [PATCH v2 00/19] PCI/TSM: TEE I/O infrastructure Aneesh Kumar K.V
2026-03-03 22:01 ` dan.j.williams
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=20260303000207.1836586-13-dan.j.williams@intel.com \
--to=dan.j.williams@intel.com \
--cc=aik@amd.com \
--cc=alistair23@gmail.com \
--cc=aneesh.kumar@kernel.org \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jgg@nvidia.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yilun.xu@linux.intel.com \
/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