VALIDATION / INVESTIGATE A FAILURE
The test passed. Is the protection path active?
A test maps device address 0x8000 to page B and has
the NIC write a 16-byte marker. Page A sits at physical
0x8000, so where the marker lands shows which path the
write took. No fault was logged, and the test reported PASS.
A pass is a claim, not evidence. Four causes fit it. Pick checks, watch causes drop out, and conclude only when one is left.
The investigation
Possible causes
Checks
The device wrote the wrong bytes. What do I check?
Follow one request in order and stop at the first hop that fails. Each check narrows the causes; it does not prove one on its own. Addresses are explained in the address legend.
| Hop | Check | What it narrows, if the request is controlled |
|---|---|---|
| Requester ID | The Command register in lspci (bus mastering) and the device ID in any fault record | Whether the device was allowed to send requests. Bus mastering permits them but does not show this one was sent, and a missing record does not show it was not: match any record to the attempt you made |
| IOMMU domain | The IOMMU's translation mode for the device | Translation bypassed (the write went straight through), versus translated, for that device |
| Translation | Invalidate, then write the same request again | Stale translation (the retry now lands on the right page) versus wrong mapping (it still lands on the wrong one). Only if the invalidation covered every cache that could hold the entry (the IOMMU's and the device's), completed before the retry, and the mapping did not change meanwhile |
| Memory | Read the intended page and the page that was hit | Where the bytes went, once visibility and ordering are controlled. It does not say why that page was chosen |
| Completion | How many of the bytes arrived, and whether the command or transfer completed (what a completion proves) | Incomplete work (a partial or unfinished transfer) versus the wrong destination |
| Interrupt | Is the data right in RAM while the driver was never told? | A missing interrupt (notification path), which is not a data bug |
Same symptom, different layer
| You see | Evidence that points to it | What that evidence cannot establish |
|---|---|---|
| Device not enumerated | Missing from lspci | Anything about DMA or the driver: it never got that far |
| BAR access failure | Reads come back all ones (a common sign), memory space not enabled or BAR unassigned in lspci -vv | Whether the device, the link or the BAR assignment is at fault |
| DMA fault | An event-log record with the device and address | Why the mapping was absent or denied |
| NIC policy drop | A drop counter on the NIC (ethtool -S) with no IOMMU event | That the DMA path itself is healthy |
| DMA succeeded, no guest notification | The bytes are in RAM; the interrupt count did not move | Whether the device sent no interrupt or the interrupt path dropped it |
The method behind it
- Hypotheses first. List every cause that fits the symptom before reading anything, so a check can rule one out.
- One variable at a time. Each check reads one thing or changes one thing (unmap, or invalidate), so a change in the result has fewer competing explanations; within this exercise's four declared causes it can point to one.
- Regression. Keep the checks that told the causes apart as the test: write the marker, assert which page it reached, then the denied probe and the recovery. A pass then means the path, not only the status.
- An empty fault log rules out nothing. Every cause above leaves it empty.
- Positive control: look where the bytes landed, not only at the status.
- Denied probe: take the permission away and show the same request now fails, and why.
- Recovery control: invalidate, retry, and show the path works again.
- Stop when the evidence leaves one cause. A conclusion is justified when the evidence rules out the other causes you considered.
The same steps, on the emulated IOMMU: show that the intended protection path is active. Each cause has its own chapter: stale IOTLB entries, bus mastering and faults and recovery.