Re: [RISC-V] [tech-virt-mem] Access faults for paging structures linked to hgatp


Anup Patel
 

Hi Paolo,

´╗┐On 12/07/21, 4:42 PM, "tech-virt-mem@... on behalf of Paolo Bonzini" <tech-virt-mem@... on behalf of pbonzini@...> wrote:

On 12/07/21 05:30, Anup Patel wrote:
> * Any wrong memory access done by Guest/VM (VS-level) via explicit
> load/store instruction or via VS-stage page table walk will result
> in Guest page fault taken by hypervisor. The hypervisor can handle
> invalid memory access from Guest/VM by either to killing the
> Guest/VM or by injecting an access fault to Guest/VM where the later
> is generally preferred approach for hypervisors.

Why wouldn't this actually be taken by the M-level firmware, and from
there forwarded twice (first to the hypervisor and second to the guest
OS)? medeleg would be the same as in the case below.

Over here wrong memory access by Guest/VM means, Guest accessing
memory not mapped in G-stage (Stage2). The M-level firmware delegates
all Guest page faults to HS-level so all Guest page faults are directly taken
by hypervisor.

The little tricky case is when hypervisor has done incorrect mapping in
G-stage (Stage2) which point to non-existent (or not-accessible) address.
In this case, access to such non-existent (or not-accessible) memory
will result in access fault which is first taken by M-level firmware and
then forwarded to hypervisor.

Regards,
Anup

Paolo

> * Any wrong memory access done by Hypervisor (HS-level) via explicit
> load/store instruction or via S-stage page table walk or via G-stage
> page table walk will result in access fault taken by M-level runtime
> firmware (OpenSBI). The M-level runtime firmware will typically
> redirect the access fault back to the HS-level software (Hypervisor).

Join tech-privileged@lists.riscv.org to automatically receive all group messages.