Description
I am seeking clarification on the architectural assumptions behind the PCIe Memory Model tests, specifically comparing PCI_MM_01 (p045.c) and PCI_MM_03 (p094.c).
Observation
Upon reviewing the test implementations, there is a fundamental difference in how PCIe BAR space is mapped and accessed:
PCI_MM_01 (p045.c): Uses DEVICE_nGnRnE attributes to map the PCIe BAR(s) and validates aligned 32-bit accesses. This aligns with the standard architectural expectation for generic Device memory where side effects are unknown.
PCI_MM_03 (p094.c): Uses NORMAL_NC (Normal Non-Cacheable) attributes to map the PCIe BAR(s) and specifically checks for unaligned byte accesses.
The Concern
My understanding is that mapping a PCIe BAR as NORMAL_NC is only safe when the nature of the BAR is known beforehand (e.g., it is a linear framebuffer or a memory-like data buffer). In the context of a generic compliance test suite like BSA/SBSA ACS:
Attribute Mismatch: NORMAL_NC allows for gathering, reordering, and—critically—speculative reads. If a BAR contains "read-to-clear" registers or FIFO interfaces, mapping it as Normal memory can trigger unintended side effects that corrupt the device state.
Unaligned Accesses: While Normal memory supports unaligned accesses, many PCIe endpoints do not. Triggering an unaligned access to a device that expects strict alignment (often enforced by Device memory types) could result in an External Abort or undefined behavior.
Test Validity: Since the ACS does not have prior knowledge of the specific IP behind the BAR, why is NORMAL_NC considered a valid mapping for a generic test case?
Inquiry
What is the justification for using NORMAL_NC in PCI_MM_03 without knowing the endpoint's behavior?
Should this test be restricted only to certain classes of devices (e.g., those reporting as Prefetchable Memory in the PCI Configuration Space)?
Is there a risk that this test might cause false negatives (or system instability) on hardware that strictly adheres to Device memory semantics?
Description
I am seeking clarification on the architectural assumptions behind the PCIe Memory Model tests, specifically comparing PCI_MM_01 (p045.c) and PCI_MM_03 (p094.c).
Observation
Upon reviewing the test implementations, there is a fundamental difference in how PCIe BAR space is mapped and accessed:
PCI_MM_01 (p045.c): Uses DEVICE_nGnRnE attributes to map the PCIe BAR(s) and validates aligned 32-bit accesses. This aligns with the standard architectural expectation for generic Device memory where side effects are unknown.
PCI_MM_03 (p094.c): Uses NORMAL_NC (Normal Non-Cacheable) attributes to map the PCIe BAR(s) and specifically checks for unaligned byte accesses.
The Concern
My understanding is that mapping a PCIe BAR as NORMAL_NC is only safe when the nature of the BAR is known beforehand (e.g., it is a linear framebuffer or a memory-like data buffer). In the context of a generic compliance test suite like BSA/SBSA ACS:
Attribute Mismatch: NORMAL_NC allows for gathering, reordering, and—critically—speculative reads. If a BAR contains "read-to-clear" registers or FIFO interfaces, mapping it as Normal memory can trigger unintended side effects that corrupt the device state.
Unaligned Accesses: While Normal memory supports unaligned accesses, many PCIe endpoints do not. Triggering an unaligned access to a device that expects strict alignment (often enforced by Device memory types) could result in an External Abort or undefined behavior.
Test Validity: Since the ACS does not have prior knowledge of the specific IP behind the BAR, why is NORMAL_NC considered a valid mapping for a generic test case?
Inquiry
What is the justification for using NORMAL_NC in PCI_MM_03 without knowing the endpoint's behavior?
Should this test be restricted only to certain classes of devices (e.g., those reporting as Prefetchable Memory in the PCI Configuration Space)?
Is there a risk that this test might cause false negatives (or system instability) on hardware that strictly adheres to Device memory semantics?