Incompatible test result in ATS InD=1 request
Closed this issue · 1 comments
2.2.3. Process-context fields
When ENS is 1, supervisor privilege transactions that read with execute intent to pages mapped with U bit in PTE set to 1 are disallowed, regardless of the value of SUM.
According to the above IOMMU specification statements, PnU=1, U=1 should resullt in a translation fault in the reference model regardless of ENS:
// When ENS is 1, supervisor privilege transactions that read with
// execute intent to pages mapped with U bit in PTE set to 1 will fault,
// regardless of the state of SUM.
if ( is_exec && (priv == S_MODE) && (pte->U == 1) ) goto page_fault;
...
page_fault:
// Stop and raise a page-fault exception corresponding
// to the original access type.
if ( is_exec ) *cause = 12; // Instruction page fault
else if ( is_read ) *cause = 13; // Read page fault
else *cause = 15; // Write/AMO page fault
return 1;
This check is enforced regardless of ATS. Then the problem can be seen against the InD=1, ATS=1 sanity check affected by the above code. Following the faulting code path, the reference model could generate faults indicating "instruction S/G stage page fault"; while in DTI-ATS responses, we can only have write, read fault like the following since there is no "executable sence" applicable to the PCIe requesting devices.
if (ats)
s/g_perm_fault = pnu ? (priv_write_fault & priv_read_fault) : (user_write_fault & user_read_fault);
This looks reasonable from PCIe's point of view. Shall we change the reference model a bit to be compatible with the real world?
By ATS=1
do you mean the transaction is a memory read with address type set to PCIe ATS Translation Request? For a ATS Translation Request, this case should lead to a response with status value as Success and with Read and Write bits clear. In the code you quote the execution then continues at the label stop_and_report_fault
where the response and whether fault is logged is determined.