Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lspci: Add support for the DOE Discovery options #152

Closed

Conversation

alistair23
Copy link

The PCIe 6 specification added support for the Data Object Exchange (DOE). When DOE is supported the Discovery Data Object Protocol must be implemented. The protocol allows a requester to obtain information about the other DOE protocols supported by the device.

This patch adds support for querying the list of DOE Discovery Data Object Protocols supported by the device.

This unfortunately does require writing to the device, as we can't query the information without sending data objects to the device.

The PCIe 6 specification added support for the Data Object Exchange
(DOE). When DOE is supported the Discovery Data Object Protocol must be
implemented. The protocol allows a requester to obtain information about
the other DOE protocols supported by the device.

This patch adds support for querying the list of DOE Discovery Data
Object Protocols supported by the device.

This unfortunatley does require writing to the device, as we can't
query the information without sending data objects to the device.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
@jic23
Copy link
Contributor

jic23 commented Jul 18, 2023

Hi Alistair,

Whilst I'd love to see this... It is not safe to do unmediated accesses to the DOE if there is any potential for a driver being bound to it, (or shortly in Linux at least if the PCI core is using it). You can end up reading and clearing the response to someone else's request - and drivers tend not to assume someone will steal their data from under them. That's particularly 'fun' if you break a security related transfer and end up taking down the device due to a key refresh or similar failing.

From linux side of things, we decided early on that any access must be mediated by the PCI driver stack. I'd imagine other operating systems will do the same. So this path is a non starter as far as I'm concerned.

For Linux, we could add some sysfs files to provide this information given it will have been queried anyway on all PCI devices that have DOEs (after Lukas finishes the CMA / attestation support). lspci could read that. If you have a specific protocol that is of interest to you then we should look at a proper safe userspace interface.

@gollux
Copy link
Contributor

gollux commented Jul 19, 2023

I completely agree that this should not be done by default. In particular, lspci without special options should never write to configuration registers.

I can imagine implementing this as a separate tool for debugging hardware, but I believe that the right place is in the kernel.

@alistair23
Copy link
Author

I suspected writing directly to the device wasn't a viable upstream solution.

I wanted to get some feedback about if this is something we wanted to do in userspace via special arguments or it it had to be in the kernel. It sounds like the kernel is the place to do this and then we can query the information from there. I'll work towards that

@alistair23 alistair23 closed this Jul 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants