Hi Maheedhar, Previously, the RXPX check was still being performed, but its result was simply ignored. This patch changes that behavior by enforcing failures when the check doesn't pass. There are two scenarios where the RXPX check is applied: one under EM_NOT_AFFECTED and the other under EM_HIGHER_EL_MITIGATION.
* In the EM_NOT_AFFECTED case, the CPU revision should fall outside the erratum’s affected range. * In the EM_HIGHER_EL_MITIGATION case, where mitigation has been applied at a higher exception level, the CPU revision should be within the affected range.
The RXPX check validates both of these expectations. If it fails in either case, it typically indicates a mismatch between the ABI test case and the actual errata check logic. If a CPU revision falls outside the test case range but is categorized under EM_HIGHER_EL_MITIGATION, that should be treated as a failure. If you're seeing a situation that doesn't align with these conditions and could share some more info—I'd be happy to take a look,
Regards, Arvind
Bollapalli, Maheedhar Sai wrote:
[AMD Official Use Only - AMD Internal Distribution Only] Hi TF-A-Tests team, We are observing EM-ABI tests failures with latest Tf-a-tests upstream code where-in CPU revision is retrieved and RXPX range is compared based on the errata list per CPU core and if the CPU revision is outside of the errata revision range test case is deemed as failure, which doesn't seem to be appropriate. Patch change that marked RXPX out of range as failure. Change that marks range check as test failure: https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/he... Patch: https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/5668f34... Regards, Maheedhar.