On 25/2/25 09:31, Dan Williams wrote:
Aneesh Kumar K.V wrote:
Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx> writes:
On Tue, Dec 10, 2024 at 08:49:40AM +0530, Aneesh Kumar K.V wrote:
Hi Dan,
Dan Williams <dan.j.williams@xxxxxxxxx> writes:
+int pci_ide_stream_setup(struct pci_dev *pdev, struct pci_ide *ide,
+ enum pci_ide_flags flags)
+{
+ struct pci_host_bridge *hb = pci_find_host_bridge(pdev->bus);
+ struct pci_dev *rp = pcie_find_root_port(pdev);
+ int mem = 0, rc;
+
+ if (ide->stream_id < 0 || ide->stream_id > U8_MAX) {
+ pci_err(pdev, "Setup fail: Invalid stream id: %d\n", ide->stream_id);
+ return -ENXIO;
+ }
+
+ if (test_and_set_bit_lock(ide->stream_id, hb->ide_stream_ids)) {
+ pci_err(pdev, "Setup fail: Busy stream id: %d\n",
+ ide->stream_id);
+ return -EBUSY;
+ }
+
Considering we are using the hostbridge ide_stream_ids bitmap, why is
the stream_id allocation not generic? ie, any reason why a stream id alloc
like below will not work?
Should be illustrating in commit log.
"The other design detail for TSM-coordinated IDE establishment is that
the TSM manages allocation of stream-ids, this is why the stream_id is
passed in to pci_ide_stream_setup()."
This is true for Intel TDX.
IIUC ide->stream_id is going to be set by SVE or TDX backend. But then
we also expect the below.
if (test_and_set_bit_lock(ide->stream_id, hb->ide_stream_ids)) {
pci_err(pdev, "Setup fail: Busy stream id: %d\n",
This is an after-the-fact "trust but verify" sanity check. It is making
sure that the Linux-view and TSM-view of the Stream ID space stays in
sync.
Hence the confusion why the stream-id cannot be allocated by the generic
TSM module as below
...again, because Linux has no way to convey which Stream ID to use to
the TSM.
The AMD PSP fw allows the OS to choose streamids (have not tested
anything but "0" but all the API is there) and the OS programs these to
both ends of PCIe link via the IDE cap. Is it different elsewhere? Thanks,
--
Alexey
