0
\$\begingroup\$

On a Windows system there is a PCI Express (PCIe) endpoint device with an application design that handles TLPs from Windows.

The design is being updated, and I want to leave out some previous functionality, that I expect is unused.

However, I want to generate an error back to Windows if the application design receives a TLP that tries to access some of the left out functionality, so I can detect this problem.

Both posted (write) and non-posted (read) TLPs could potentially access such left out functionality, so error reporting should be possible for both types of TLPs.

Added: There existing application SW on Windows should be able to run without modifications, and when the design is complete, no errors should be generated due to access to removed features.

What is the best way to generate error back to Windows in this case?

\$\endgroup\$

2 Answers 2

1
\$\begingroup\$

This sounds like something that would be best served with an interrupt - be that legacy or MSI.

When your driver tries to access a no longer implemented region of memory, the device should detect this access (compare the address of the TLP), and in response generate an interrupt. You should also have some register in your device that stores interrupt flags, into which you can add a new "invalid access" or similar flag for this.

The driver detects the interrupt, and checks the source of the interrupt. If the invalid access flag is set, then your driver knows what it's done wrong.

\$\endgroup\$
5
  • \$\begingroup\$ Thanks for the suggestion; one requirement through (and I have added it above) is that the existing application SW on Windows SW can run unchanged, to it is not possible to add a new interrupt feature to report error. \$\endgroup\$
    – EquipDev
    Commented Apr 12, 2021 at 17:04
  • 1
    \$\begingroup\$ @EquipDev If you can't change the Windows driver, then you aren't going to be able to handle any form or extra error. About all you could do then is ignore the writes/reads in the PCIe endpoint, in which case writes will dissappear into a black hole and reads will end up returning 0xFF (windows PCI(e) driver will handle the lack of read response and turn it into lots of 0xFF's.) \$\endgroup\$ Commented Apr 12, 2021 at 17:47
  • \$\begingroup\$ The idea I have, is that Windows will maybe handle an error in a kind of generic way, so for example, if an access from the application SW to PCIe results in an error, like Completer Abort (CA) error, then Windows will catch and report that error, shut down the application. In that case SW changes would not be required, since Windows does already have the ability to handle such errors. Is there any possibilities like that ? \$\endgroup\$
    – EquipDev
    Commented Apr 12, 2021 at 20:05
  • 1
    \$\begingroup\$ @EquipDev for a PCIe device, you'll have a kernel mode driver. If that is not well designed to handle whatever you choose to do with the hardware, any crash will BSOD windows. The simplest thing to try is to just not respond in your device to any requests for the no longer valid address, and see how the existing software handles it. If it handles it fine, you are set. If not the software will need changing. \$\endgroup\$ Commented Apr 12, 2021 at 22:09
  • \$\begingroup\$ NOTE: This answer was also chosen based on the good and relevant comments added by the answerer, thus not solely due to the answer itself. \$\endgroup\$
    – EquipDev
    Commented Apr 15, 2021 at 16:44
2
\$\begingroup\$

There is PCIe AER, which is a standardized format for error messages on PCIe, that has explicit error codes for unsupported transactions.

On Windows, this is reported through WHEA, on Linux, it shows up in the kernel log files in the absence of explicit driver support.

My expectation for Windows is that there, too, unhandled AER reports go into some sort of communal error log.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks, I found info about PCIe Advanced Error Reporting (AER) in the Mindshare PCI Express Technology books. \$\endgroup\$
    – EquipDev
    Commented Apr 12, 2021 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.