Test 830 - pass on UR detected bit set (PR issue Ported from SBSA)

[Sujana-M]

Original PR: ARM-software/sbsa-acs#562

Neither reading 0xFFFFFFFF from the BAR nor receiving a SERROR by external abort are within the scope of the PCIe specification. Instead of relying on either of these behaviors, check the UR detected bit within the device status register to confirm a UR has been signalled.

Note - The bit is already being cleared on each EP before reading the BAR.

@erirow01
Test 830 - pass on UR detected bit set
e0bce01

[sunnywang-arm]
I think this is a valid point. The SBSA test 830 is based on the SBSA rules RE_REG_1, IE_REG_1, IE_REG_3, and those three rules are redirecting to the rules in the PCIe specification. According to the PCIe specification, An Unsupported Request (UR) does not inherently imply a return of all 1's data. Therefore, it seems more appropriate for the test to check the UR detected bit in the device status register instead of relying on all 1's data. Checking all 1's data for UR is good for getting better compatibility with legacy software in some cases (especially related to root ports), but probably it is not needed for this "access to BAR" case.

Cc @chetan-rathore @gowthamsiddarthd

[Sujana-M]
Hi @erirow01

The PCIe spec mentions:
"If the Requester needs to report the error, the Requester must do so solely through a Requester-specific mechanism. For
example, many devices have an associated device driver that can report errors to software. As another important
example, the Root Complex on some platforms returns all 1’s to software if a Configuration Read Completion has a UR/
CA Status... Requesters are not permitted to report the error using PCI Express logging and error Message signaling."

When MSE is disabled, this request us treated as a UR completion. PCIe forbids logging UR in device status for outbound requests. Hence the UR bit isn't checked

Thanks,
ACS Team

@[erirow01]
If the purpose of the test is to verify implementation-defined behavior, then it is arguably not a PCIe test. My concern is that the test will break in the future as new requester-specific mechanisms are added (as seen in FVP models rdv3/rdv3cfg1).

When MSE is disabled, this request is treated as a UR completion. PCIe forbids logging UR in device status for outbound requests. Hence the UR bit isn't checked

This doesn't seem to be the case from my testing of my patch. UR bit in device status is set as a result of the MMIO read when MSE is disabled.

Thanks,
Eric

cc @erirow01

[sunnywang-arm]

@Sujana-M @erirow01

I can still produce the issue on RDV3-CFG1 FVP with daily build sbsa-acs. sbsa-acs freezes at test 858 (was 830). Can we reopen the issue?

858 : Check MSE, CapPtr & BIST: RCiEP, RCEC
START
tbl_index 0
tbl_index 1
tbl_index 2
tbl_index 3
tbl_index 4
BDF - 0x1E00 Bar Base 40040000

[chetan-rathore]

Hi @sunnywang-arm,

Reopened the issue to check with latest observation