qemu: incorrect behavior for write to hgatp.ppn[1:0]

[Adnan Hamid]

This issue was discovered during detail testing of Hypervisor Extension functionality.

hgatp.PPN[1:0] is WARL and should always read zero due root page table being 16KiB and aligned to a 16-KiB
boundary.

spike ignore writes to hgatp.PPN[1:0], and drops the low two bits for address translation.
This behavior seems reasonable.

    write_csr(hgatp, 0x80000000000bdcc5); // Sv39x4, hgatp.PPN[1:0] = 0x1
    read_csr(hgatp);                      // returns 0x80000000000bdcc4, hgatp.PPN[1:0] = 0x0
    // address translation uses 0x80000000000bdcc4
    // works correctly on change to privilege PRV_VS
   
qemu accepts the misaligned write to hgatp.PPN[1:0]
   
    write_csr(hgatp, 0x80000000000bdcc5); // Sv39x4, hgatp.PPN[1:0] = 0x1
    read_csr(hgatp);                      // returns 0x80000000000bdc5, hgatp.PPN[1:0] = 0x1

qemu then generates an exception on change to privilege PRV_VS, with mcause=20, which is a Reserved value.
Presumably this occurred due to using the misaligned value 0x00000000000bdc5 as the root page table.

Expected behavior: qemu should ignore writes to hgatp.PPN[1:0], and use the aligned address for address
translation.

[Tommy Murphy]

Is this relevant here?

* https://gitlab.com/qemu-project/qemu/-/issues/1556

If not then you should probably log a new/separate issue there.

[Adnan Hamid]

Thank you Tommy, very relevant.

We were using qemu-8.1.3 from last December.

We will try with the qemu head of tree and report accordingly.

-adnan