Linux driver-core infrastructure
 help / color / mirror / Atom feed
From: Dan Williams <djbw@kernel.org>
To: linux-coco@lists.linux.dev
Cc: linux-pci@vger.kernel.org, driver-core@lists.linux.dev,
	ankita@nvidia.com, Alexey Kardashevskiy <aik@amd.com>,
	Xu Yilun <yilun.xu@linux.intel.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Subject: [PATCH 15/15] PCI/TSM: Add relative MMIO offset support?
Date: Sun,  5 Jul 2026 15:08:19 -0700	[thread overview]
Message-ID: <20260705220819.2472765-16-djbw@kernel.org> (raw)
In-Reply-To: <20260705220819.2472765-1-djbw@kernel.org>

The RMM specification, DEN0137-2.0-bet2 section A9.6.2 "Realm validation of
device memory mappings" documents the expectation that the
MMIO_REPORTING_OFFSET chosen for TDISP Interface Reports is always BAR
aligned.

Ideally this change is not needed and all implementations share the same
expectation.

If this semantic is already shipping in production and/or the PCI-SIG
clarifies that an implementation can hold this assumption then Linux will
need to ask the TSM drivers for this hint.

Cc: Alexey Kardashevskiy <aik@amd.com>
Cc: Xu Yilun <yilun.xu@linux.intel.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Signed-off-by: Dan Williams <djbw@kernel.org>
---
 include/linux/pci-tsm.h | 15 ++++++++++++++-
 drivers/pci/tsm/core.c  | 14 ++++++++++----
 2 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/include/linux/pci-tsm.h b/include/linux/pci-tsm.h
index 6d5fadd79360..be9f78ca2c1a 100644
--- a/include/linux/pci-tsm.h
+++ b/include/linux/pci-tsm.h
@@ -296,7 +296,20 @@ struct pci_tsm_devsec *to_pci_tsm_devsec(struct pci_tsm *tsm);
 int pci_tsm_mmio_setup(struct pci_dev *pdev, struct pci_tsm_mmio *mmio);
 void pci_tsm_mmio_teardown(struct pci_tsm_mmio *mmio);
 
-struct pci_tsm_mmio *pci_tsm_mmio_alloc(struct pci_dev *pdev);
+/**
+ * enum tdisp_offset_scheme - MMIO_REPORTING_OFFSET assumptions
+ * @TDISP_OFFSET_BAR_ALIGN: mask by bar size to recover offset
+ * @TDISP_OFFSET_RELATIVE: first mmio report per bar is bar-offset-0
+ *
+ * A TSM driver may know that the default TDISP_OFFSET_BAR_ALIGN
+ * assumption is being violated.
+ */
+enum tdisp_offset_scheme {
+	TDISP_OFFSET_BAR_ALIGN,
+	TDISP_OFFSET_RELATIVE,
+};
+struct pci_tsm_mmio *pci_tsm_mmio_alloc(struct pci_dev *pdev,
+					enum tdisp_offset_scheme scheme);
 int pci_tsm_mmio_free(struct pci_dev *pdev, struct pci_tsm_mmio *mmio);
 #else
 static inline int pci_tsm_register(struct tsm_dev *tsm_dev)
diff --git a/drivers/pci/tsm/core.c b/drivers/pci/tsm/core.c
index 9ac216ad896d..19ad35f2da4a 100644
--- a/drivers/pci/tsm/core.c
+++ b/drivers/pci/tsm/core.c
@@ -643,13 +643,15 @@ struct pci_tsm_devif_report {
 /**
  * pci_tsm_mmio_alloc() - allocate encrypted MMIO range descriptor
  * @pdev: device owner of MMIO ranges
+ * @scheme: allow the low level TSM driver to hint the offset calc scheme
  *
  * Return: the encrypted MMIO range descriptor on success, NULL on failure
  *
  * Assumes that this is called within the live lifetime of a PCI device's
  * association with a low level TSM.
  */
-struct pci_tsm_mmio *pci_tsm_mmio_alloc(struct pci_dev *pdev)
+struct pci_tsm_mmio *pci_tsm_mmio_alloc(struct pci_dev *pdev,
+					enum tdisp_offset_scheme scheme)
 {
 	struct device_evidence *evidence = pdev->tsm->evidence;
 	u64 reporting_bar_base, last_reporting_end;
@@ -712,10 +714,14 @@ struct pci_tsm_mmio *pci_tsm_mmio_alloc(struct pci_dev *pdev)
 			last_bar = bar;
 
 			/*
-			 * Determine the obfuscated base of the BAR. BAR
-			 * offsets are never obfuscated.
+			 * Either the first range per bar always maps
+			 * the start of the BAR, or the reporting_offset
+			 * is BAR size aligned.
 			 */
-			reporting_bar_base = tsm_offset & ~mask;
+			if (scheme == TDISP_OFFSET_RELATIVE)
+				reporting_bar_base = tsm_offset;
+			else
+				reporting_bar_base = tsm_offset & ~mask;
 		} else if (tsm_offset < last_reporting_end) {
 			pci_dbg(pdev, "Reporting ranges within BAR not in ascending order\n");
 			return NULL;
-- 
2.54.0


  parent reply	other threads:[~2026-07-05 22:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-05 22:08 [PATCH 00/15] Device Evidence and Trust for PCI Security Protocol (TDISP) Dan Williams
2026-07-05 22:08 ` [PATCH 01/15] netlink: specs: Introduce multi-message blobs for SPDM Dan Williams
2026-07-05 22:08 ` [PATCH 02/15] tools: ynl: Teach pyynl to handle blobs Dan Williams
2026-07-05 22:08 ` [PATCH 03/15] tools: ynl: Teach ynl_gen_c to validate and dump 'blob' attributes Dan Williams
2026-07-05 22:08 ` [PATCH 04/15] device core: Introduce "device evidence" over netlink Dan Williams
2026-07-05 22:08 ` [PATCH 05/15] device core: Add "device evidence" 'validate' command Dan Williams
2026-07-05 22:08 ` [PATCH 06/15] PCI/TSM: Add device evidence support Dan Williams
2026-07-05 22:08 ` [PATCH 07/15] modules: Document the global async_probe parameter Dan Williams
2026-07-05 22:08 ` [PATCH 08/15] device core: Initial device trust infrastructure Dan Williams
2026-07-06 13:45   ` Jason Gunthorpe
2026-07-05 22:08 ` [PATCH 09/15] PCI, device core: Move "untrusted" concept to DEVICE_TRUST_ADVERSARY Dan Williams
2026-07-06 13:49   ` Jason Gunthorpe
2026-07-05 22:08 ` [PATCH 10/15] PCI/TSM: Add device interface security LOCKED support Dan Williams
2026-07-05 22:08 ` [PATCH 11/15] PCI/TSM: Add device interface security RUN support Dan Williams
2026-07-05 22:08 ` [PATCH 12/15] PCI/TSM: Add device interface security DMA enable/disable Dan Williams
2026-07-05 22:08 ` [PATCH 13/15] PCI, device core: Add private memory access for DEVICE_TRUST_TCB Dan Williams
2026-07-06 12:42   ` Aneesh Kumar K.V
2026-07-05 22:08 ` [PATCH 14/15] PCI/TSM: Create MMIO descriptors via TDISP Report Dan Williams
2026-07-05 22:08 ` Dan Williams [this message]
2026-07-06 12:51 ` [PATCH 00/15] Device Evidence and Trust for PCI Security Protocol (TDISP) Jason Gunthorpe
2026-07-06 20:55   ` Dan Williams (nvidia)

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=20260705220819.2472765-16-djbw@kernel.org \
    --to=djbw@kernel.org \
    --cc=aik@amd.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=ankita@nvidia.com \
    --cc=driver-core@lists.linux.dev \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-pci@vger.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