On 27.08.2026 17:21, Oleksii Kurochko wrote: > Take the guest physical address from htval and stval: on a guest-page fault > htval holds it shifted right by 2, so that an address wider than XLEN fits, > and stval holds the faulting guest virtual address, whose two least > significant bits are those of the guest physical address. The shift is done > on paddr_t rather than on the raw register: a guest physical address is 34 > bits wide on RV32 with Sv32x4, so shifting an XLEN-wide value would drop its > top two bits. > > Those two low bits come from stval only for a fault on an explicit access. > Where one is taken on an implicit access made for VS-stage translation htval > holds the address of the VS-stage PTE which could not be read, while stval > still holds the guest virtual address which started the walk, and the low > bits of the address written to htval are zero instead. htinst tells the two > apart, which is what the spec points at it for. > > stval needs no check against an ISA extension: a guest-page fault writes it > with the faulting guest virtual address regardless. Sstvala would not be the > right thing to test for either (it covers stval across every trap type > which writes it, a wider guarantee than what is needed here). > > htval does need one. The H extension lets an implementation write it with > either the faulting address or zero, so without Shtvala a zero htval cannot > be told apart from a genuine fault on guest physical address 0-3, and the > address has to be recovered by decoding the access and walking the VS-stage > page tables in software instead. That is left as a TODO, and until it is > written such hardware panics rather than acting on an address which may not > be the one which faulted. > > Signed-off-by: Oleksii Kurochko <[email protected]>
Acked-by: Jan Beulich <[email protected]>
