On Tue, Jul 30, 2019 at 3:46 PM Paolo Bonzini <pbonz...@redhat.com> wrote: > > On 30/07/19 10:48, Paolo Bonzini wrote: > > On 29/07/19 13:56, Anup Patel wrote: > >> + cntx->hstatus |= HSTATUS_SP2V; > >> + cntx->hstatus |= HSTATUS_SP2P; > > IIUC, cntx->hstatus's SP2P bit contains the guest's sstatus.SPP bit? > > Nevermind, that was also a bit confused. The guest's sstatus.SPP is in > vsstatus. The pseudocode for V-mode switch is > > SRET: > V = hstatus.SPV (1) > MODE = sstatus.SPP > hstatus.SPV = hstatus.SP2V > sstatus.SPP = hstatus.SP2P > hstatus.SP2V = 0 > hstatus.SP2P = 0 > ... > > trap: > hstatus.SP2V = hstatus.SPV > hstatus.SP2P = sstatus.SPP > hstatus.SPV = V (1) > sstatus.SPP = MODE > V = 0 > MODE = 1 >
Yes, this kind of pseudo-code are not explicitly specified in the RISC-V spec. The RISC-V formal model is supposed to cover this kind of detailed HW state transition. > so: > > 1) indeed we need SP2V=SPV=1 when entering guest mode > > 2) sstatus.SPP contains the guest mode > > 3) SP2P doesn't really matter for KVM since it never goes to VS-mode > from an interrupt handler, so if my reasoning is correct I'd leave it > clear, but I guess it's up to you whether to set it or not. Yes, SP2P does not matter but we set it to 1 here so that from Guest perspective it seems we were in S-mode previously. Regards, Anup
