Re: [PATCH v2 09/19] PCI/TSM: Support creating encrypted MMIO descriptors via TDISP Report

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Apr 08, 2026 at 05:03:16PM +1000, Alexey Kardashevskiy wrote:
> > > This is what I am trying to clarify - if all ranges muI thinkst be reported
> > > (as some think this is what the PCIe spec says), then no, not
> > > anywhere.
> > > 
> > > pcie r7, Table 11-16 TDI Report Structure, MMIO_RANGE:
> > > 
> > > "Each MMIO Range of the TDI is reported with the MMIO reporting offset added."
> > 
> > I think the argument was something like it didn't have to report
> > non-secure ranges? But I don't know, it was hashed out in some thread
> > for ARM and then I know our folks looked at it and nobody pushed back
> > to insist that every single byte of the BAR had to be covered by a
> > reported range.
> 
> That's (my ignorant guess) because of the ARM FW TSM guy which sees the BARs and can easily make sure that MMIO_OFFSET is such that BAR alignment is preserved (and there is a clause in PCIe about how such offset is "permitted" to be calculated) => does not make much difference on ARM but it does in my case :-/
> > I wouldn't take the sentance you quoted as confirmation, you need a
> > sentance that says every single byte of the BAR is covered by a single
> > reported range.
> 
> Why "by a single range"? Every byte of a BAR needs to be covered
> (which is what my quote suggests)

No, your quote doesn't suggest that at all, it just says if a range is
present it has to be offset.

In fact the spec specifically says not to report ranges sometimes:

 Bit 0 -  MSI-X Table - if the range maps MSI-X table. This
 must be reported **only if locked** by the
 LOCK_INTERFACE_REQUEST.

So if the MSI-X table is not locked then what is reported? Seems not
covered by a range at all is the consensus answer.

Thus you get this case where the non-reported MSI-X table could be at
byte 0, not get a range and then there is no range covering byte 0 of
the bar at all.

> and the spec allows multiple ranges but also requires strict
> ascending order of the ranges, 3 paragraphs of text about
> it. Thanks,

single range per byte means there are not overlapping ranges.

This was the old thread with my suggestion.

https://lore.kernel.org/all/20250911134107.GG882933@ziepe.ca/

If this is important to AMD they need to get an ECN with PCI-SIG to
clarify. I think as of right now Linux can't assume the ranges start
at bar physical offset 0.

Jason