On 28/2/25 13:26, Dan Williams wrote:
Alexey Kardashevskiy wrote:
[..]
And it just leaves link streams unconfigured. So I have to work around
my device by writing unique numbers to all streams (link + selective)
I am not using. Meh.
This sounds like a device-quirk where it is not waiting for an enable
event to associate the key with a given stream index. One could imagine
this is either a pervasive problem and TSMs will start considering
Stream ID 0 as burned for compatibilitiy reasons. Or, this device is
just exhibiting a pre-production quirk that Linux does not need to
react, yet.
The hw people call it "the device needs to have an errata" (for which we
will later have a quirk?).
It would be great if by the time this device hit production that problem
could be fixed, but hey, errata happens.
Unlikely though.
Can you say whether this problem is going to escape your test bench into
something mainline Linux needs to worry about?
Likely going to escape, unless the PCIe spec says specifically that this
is a bug. Hence
Linux has a role to play here in influencing what is acceptable in
advance of the specification catching up to provide an implementation
clarification.
https://github.com/aik/linux/commit/745ee4e151bcc8e3b6db8281af445ab498e87a70
I would not expect the core to have a "Some devices insist on streamid
to be unique even for not enabled streams" path that gets inflicted on
everything unless it is clear that this bug is not not limited to this
one device.
Also, I expect the workaround needs to be re-applied at every Stream
establishment event especially to support TSM implementations that
allocate the Stream ID. I.e. it is presumptuous for the core to assume
that it can pick Stream IDs at pci_ide_init() time.
True.
It would be great if Linux could just say "the maximum number of
potential Stream IDs is 255 (instead of 256). All TSM implementations
must allocate starting at 1". Then this conflict never exists for the
default Stream ID 0 case. That is, if this problem is widespread.
Better if the PCIe spec said that but yeah, this would do.
Otherwise, at pci_ide_stream_setup() time I expect that the core would
need to do something gross like check the incoming Stream ID and walk
all idle streams to make sure they are not aliasing that ID.
This is what PCIe spec suggests doing now imho.
And then what are we doing to do when we start adding link streams? I
suggest decoupling pci_ide::stream_id from stream_id in sel_ide_offset()
(which is more like selective_stream_index) from the start.
Setting aside that I agree with you that Stream index be separated from
from Stream ID, what would motivate Linux to consider setting up Link
Stream IDE?
One of the operational criticisms of Link IDE is that it requires adding
more points of failure into the TCB where a compromised switch can snoop
traffic. It also adds more Keys and their associated maintainenace
overhead. So, before we start planning ahead for Link IDE and Selective
Stream IDE to co-exist in the implementation, I think we need a clear
use case that demonstrates Link IDE is going to graduate from the
specification into practical deployments.
Probably for things like CXL which connect directly to the soc? I do not
really know, I only touch link streams because of that only device which
is like to see the light of the day though.
CXL TSP is a wholly separate operation model and it expects that CXL
devices, and more specifically CXL memory, are inside the TCB before the
OS boots. So there is no current need for Linux to consider Link IDE for
CXL.
Link IDE or any IDE? I know very little about CXL but some of those
device types are not just simple fast memory but also do read/write
from/to that memory so they cannot rely on CPU memory encryption and IDE
makes sense for those (especially Link IDE as there are no bridges, or
are there?). Thanks,
We can always cross that sophistication bridge later.
Today SEV-TIO does not do link streams at all so I am with you :) Thanks,
Sounds good.
--
Alexey
