Re: [PATCH 4/7] x86/ioremap, resource: Introduce IORES_DESC_ENCRYPTED for encrypted PCI MMIO

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Aug 26, 2025 at 08:52:56PM -0700, Dan Williams wrote:
> 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. Adjust the resource tree walk to use walk_iomem_res_desc() and
> check all intersecting resources for the IORES_MUST_ENCRYPT determination.

I was just looking at the ioremap stuff from the core mm side, and I
really don't understand this patch. I agree with the commit message
though..

What I expect to see in this series is not x86 code (that should be in
a series enabling x86 TSM!) but code to update the pgprot_decrypted()
calls in io_remap_pfn_range() so they are conditional.

And futher code to validate that the pfn range requested by
io_remap_pfn_range() on a TEE secured device is one that has been
checked and validated with the TSM as being actually authentic and
private.

Bascially when a driver on a T=1 struct device calls
io_remap_pfn_range() it must be private MMIO, enforced by core code.

That probably does involve a new IORES_DESC_ENCRYPTED flag..

Jason