On 25/2/25 11:06, Dan Williams wrote:
Alexey Kardashevskiy wrote:
[..]
access to set T-bit). The device got just one (which is no use here as I
understand).
I also have no idea from SPEC how to use the IDE register blocks on EP,
except stream ENABLE bit.
Well, there is another problem.
My other test device has 1 link stream and 1 selective stream, both have
streamid=0 and enable=0 after reset. I only configure 1 selective stream
(write streamid + enable) and do not touch the link stream.
But the device assumes 2 streams have the same streamid=0 and when it
receives KEY_PROG, it semi-randomly assigns the key to the link stream
in my case so things do not work. The argument for it is: every stream
needs to have an unique id, regardless its enabled state as "enable" can
come before or after key programming (and I wonder if somebody else
interprets it the same way).
This patch assumes that the selective streamid is the same as its index
in the IDE cap's list of selective streams.
Oh, true that should be separated, and perhaps that is the concern that
Aneesh has been raising as well?
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?).
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
https://github.com/aik/linux/commit/745ee4e151bcc8e3b6db8281af445ab498e87a70
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.
We can always cross that sophistication bridge later.
Today SEV-TIO does not do link streams at all so I am with you :) Thanks,
--
Alexey
