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. > > 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. 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. 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. > >> 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. > > 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.
