lkml.org 
[lkml]   [2019]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC PATCH 04/16] RISC-V: KVM: Implement VCPU create, init and destroy functions
On Tue, Jul 30, 2019 at 3:46 PM Paolo Bonzini <pbonzini@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

\
 
 \ /
  Last update: 2019-07-30 13:47    [W:0.198 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site