Scenario: CXL Type 3 Memory Invisible to OS

Scenario

Firmware logs show successful CXL.io enumeration and mailbox READY, but the OS installer sees no expanded memory. ACPI tables list the device but HDM decode registers show overlapping MMIO with a GPU BAR reassigned during OS boot.

OBSERVED METRIC
HDM region visibility and OS memory hotplug registration success.

45-MINUTE INTERVIEW FLOW
0-5: scope traffic and SLA context
5-15: map first failing PCIe/CXL layer
15-25: identify proving artifacts
25-35: propose bounded fix with owner
35-45: state validation matrix and rollback

Common pitfalls

• Assume driver issue before validating HDM decode and resource conflict.

• Enable CXL.mem without firmware-first region metadata handoff.

• Ignore BAR reallocations between UEFI and OS phases.

Scenario debrief

Score candidate response on traffic framing, timing proof, mitigation boundedness, and regression discipline.

request stream -> controller policy -> PCIe/CXL timing behavior -> measured outcome

latency/bandwidth trend

Debrief prompts

1. Which PCIe/CXL timing or queue behavior fails first in evidence?

2. Which smallest safe controller, PHY, or policy change addresses it?

3. Which benchmark + counter gate proves closure under production traffic?

Key takeaways

• Always tie controller and PHY counter shifts to application latency and throughput outcomes.

• Lock firmware timing profile, thermal condition, and DIMM state before comparing PCIe/CXL captures.

Common pitfalls

• Chasing peak bandwidth while ignoring p99 latency and fairness tails.

• Changing timing guardbands without separating SI noise from scheduling issues.

• Declaring closure without reliability gates, fault injection, and regression replay.