External email: Use caution opening links or attachmentsYes. We indeed have a system with Firmware-Controlled AER.
On Thu, Jan 04, 2024 at 08:01:06PM +0530, Vidya Sagar wrote:
On 8/1/2023 1:29 AM, Lukas Wunner wrote:
As an alternative to disabling ACS, have you explored masking ACS
Violations (PCI_ERR_UNC_ACSV) upon de-enumeration of a device and
unmasking them after assignment of a bus number?
I explored this option and it seemed to work as expected. But, the issue
is that this works only if the AER registers are owned by the OS. If the
AER registers are owned by the firmware (i.e. Firmware-First approach of
handling the errors), OS is not supposed to access the AER registers and
there is no indication from the OS to the firmware as to when the
enumeration is completed and time is apt to unmask the ACSViolation
errors in the AER's Uncorrectable Error Mask register.
Any thoughts on accommodating the Firmware-First approach also?
Are you actually using firmware-controlled AER or is it a theoretical
question?
It looks like this _DSM is totally dependent on the port having SFI
PCI Firmware Spec r3.3 sec 4.6.12 talks about a _DSM to disable DPC
on surprise-hotplug-capable ports. Maybe that would be an option?
Theoretically the answer seems to be yes, but, since the platform we
BTW what happens if the system resumes from sleep and a device in
a hotplug-capable port doesn't have a bus number configured yet
(because it's been powered off and is now in D0uninitialized state)?
Could the ACS Violations then occur as well? Do we have to maskAgain, how to do that in a system where AER is not handled natively in
ACS Violations *generally* on Root Ports and Downstream Ports when
going to system sleep and unmask them after setting a bus number
in the attached device on resume? And I suppose that would not
only be necessary for hotplug ports?
Thanks,
Lukas