Riscv Virtual Address Translation Process

[qqli579]

I recently added sv48 support under gem5's riscv. I saw the Virtual Address Translation Process on page 62 of the 《riscv-privileged-v1.10.pdf》 manual as follows:

1. Let a be satp:ppn × PAGESIZE, and let i = LEVELS − 1. (For Sv32, PAGESIZE=2^12 and
LEVELS=2.)
2. Let pte be the value of the PTE at address a+va:vpn[i]×PTESIZE. (For Sv32, PTESIZE=4.)
If accessing pte violates a PMA or PMP check, raise an access exception.
3. If pte:v = 0, or if pte:r = 0 and pte:w = 1, stop and raise a page-fault exception.
4. Otherwise, the PTE is valid. If pte:r = 1 or pte:x = 1, go to step 5. Otherwise, this PTE is a
pointer to the next level of the page table. Let i = i − 1. If i < 0, stop and raise a page-fault
exception. Otherwise, let a = pte:ppn × PAGESIZE and go to step 2.
5. A leaf PTE has been found. Determine if the requested memory access is allowed by the
pte:r, pte:w, pte:x, and pte:u bits, given the current privilege mode and the value of the SUM
and MXR fields of the mstatus register. If not, stop and raise a page-fault exception.
6. If i > 0 and pa:ppn[i − 1 : 0] 6= 0, this is a misaligned superpage; stop and raise a page-fault
exception.
7. If pte:a = 0, or if the memory access is a store and pte:d = 0, either raise a page-fault
exception or:
• Set pte:a to 1 and, if the memory access is a store, also set pte:d to 1.
• If this access violates a PMA or PMP check, raise an access exception.
• This update and the loading of pte in step 2 must be atomic; in particular, no intervening
store to the PTE may be perceived to have occurred in-between.
8. The translation is successful. The translated physical address is given as follows:
• pa.pgoff = va.pgoff.
• If i > 0, then this is a superpage translation and pa:ppn[i − 1 : 0] = va:vpn[i − 1 : 0].
• pa:ppn[LEVELS − 1 : i] = pte:ppn[LEVELS − 1 : i]

In step 8, if i > 0, then：

 If i > 0, then this is a superpage translation and pa:ppn[i − 1 : 0] = va:vpn[i − 1 : 0].

But the implementation in the doTranslate function in src/arch/riscv/tlb.cc of gem5 is like this:

Addr paddr = e->paddr << PageShift | (vaddr & mask(e->logBytes));

PageShift is a constant 12. e->logBytes and e->paddr are from
Obtained by the stepWalk function in the file src/arch/riscv/pagetable_walker.cc：

                    // perform step 8 only if pmp checks pass
                    if (fault == NoFault) {

                        // step 8
                        entry.logBytes = PageShift + (level * LEVEL_BITS);
                        entry.paddr = pte.ppn;
                        entry.vaddr &= ~((1 << entry.logBytes) - 1);
                        entry.pte = pte;
                        // put it non-writable into the TLB to detect
                        // writes and redo the page table walk in order
                        // to update the dirty flag.
                        if (!pte.d && mode != BaseMMU::Write)
                            entry.pte.w = 0;
                        doTLBInsert = true;
                    }

Is there something wrong with this implementation? Is the correct implementation supposed to be like this?

Addr paddr = ((e->paddr >> (e->logBytes - PageShift)) << e->logBytes) | (vaddr & mask(e->logBytes));

The translateWithTLB function should also be modified to:

Addr
TLB::translateWithTLB(Addr vaddr, uint16_t asid, BaseMMU::Mode mode)
{
    TlbEntry *e = lookup(vaddr, asid, mode, false);
    assert(e != nullptr);
    return ((e->paddr >> (e->logBytes - PageShift)) << e->logBytes) | (vaddr & mask(e->logBytes));
}

[hnpl]

I haven't looked into your paddr generation code in detail, but you're probably right.
The current paddr generation works well with 4KiB pages, but it probably doesn't work with non 4KiB pages.
Can you make an issue for this?