riscv-non-isa/riscv-iommu

Why the bit 0 of iotval2 is 1 in the process to locate the PC?

Closed this issue · 1 comments

In the spec, the bit 0 of iotval2 is set for first-stage address translation. And the first-stage translates VA to GPA and the second-stage translates the GPA to SPA. So the translation in the process of the location about the PC is the second-stage translation and the bit 0 of iotval2 should be 0 as the description in the spec. But in the c_model, when translating GPA to SPA, the bit 0 of iotval2 also is asserted. And so which one of them is wrong?

If bit 0 of iotval2 is 1, then the guest-page-fault was caused by an implicit memory access for first-stage address translation. If bit 0 of iotval2 is 1, and the implicit access was a write then bit 1 of iotval2 is set to 1 else it is set to 0.

https://github.com/riscv-non-isa/riscv-iommu/blob/40367b0ccdc39844df4561b662de11cfcd6daa12/iommu_ref_model/libiommu/src/iommu_process_context.c#L73C1-L89C10

step_2:
a = a + ((i == 0) ? (PDI[i] * 16) : (PDI[i] * 8));
// 2. If DC.iohgatp.mode != Bare, then a is a GPA. Invoke the process
// to translate a to a SPA as an implicit memory access. If faults
// occur during G-stage address translation of a then stop and the fault
// detected by the G-stage address translation process. The translated a
// is used in subsequent steps.
if ( ( gst_fault = second_stage_address_translation(a, 1, device_id, 1, 0, 0, 1, process_id,
0, 0, ((DC->iohgatp.MODE == IOHGATP_Bare) ? 0 : 1),
DC->iohgatp.GSCID, DC->iohgatp, DC->tc.GADE, DC->tc.SXL, &a,
&gst_page_sz, &g_pte) ) ) {
if ( gst_fault == GST_PAGE_FAULT ) {
*cause = 21; // Read guest page fault
*iotval2 = (a & ~0x3);
*iotval2 |= 1;
return 1;
}

I find it in the notice.Please delete the issue to avoid distracting people from finding what they want