Re: [PATCH v3 12/39] xen/riscv: save and restore vsiselect on vCPU context switch

[Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>]

> vsiselect is a per-hart CSR which a guest changes on its own: when V=1,
> VS-mode accesses to siselect are really accesses to vsiselect.
> Architecturally a vCPU has to find there the value it last wrote, but as
> long as the CSR isn't part of the vCPU context it finds whatever selector
> the vCPU which ran on the hart before it left behind. A guest which writes
> siselect, is descheduled and then reads sireg without rewriting siselect
> therefore reaches a register it never selected, and it can also observe
> another guest's selector value.
Nit: I'd suggest a more tighter version that might be more clear. Feel
free to use it:

    ```
    vsiselect isn't saved/restored, yet the guest writes it directly (VS-mode
    accesses to siselect go to vsiselect). After a context switch a vCPU
    therefore sees the selector left by the previous vCPU on that hart: a guest
    writing siselect, getting descheduled, then accessing sireg hits a register
    it never selected, and it can observe another guest's selector value.
    ```

> 
> When Smstateen is implemented, access to vsiselect and vsireg is gated by
> hstateen0.CSRIND (bit 60, SMSTATEEN0_SVSLCT in Xen's headers), and
> v->arch.hstateen0 holds the bits vcpu_csr_init() ended up with. A clear
> bit there covers the two cases in which the CSR has to be skipped:
> 
>  - Xen didn't hand the guest access to it, so the guest can't have changed
>    the CSR and there is no state to preserve;
>  - M-mode denied the state altogether. Smstateen makes a bit which is zero
>    in mstateen0 read-only zero in hstateen0, and a zero bit in mstateen0
>    traps accesses from every privilege mode less privileged than M-mode,
>    HS-mode included, so Xen couldn't even read the CSR to save it.
> 
> Without Smstateen no bit controls access to the CSR, so it is saved and
> restored whenever Ssaia is available.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>

Reviewed-by: Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>

-- 
Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>