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

[Oleksii Kurochko <oleksii.kurochko@gmail.com>]

On 10/7/26 10:53 AM, Baptiste Le Duc wrote:
>> 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.
>      ```
> 

that's clearer. I'll take it.

>>
>> 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@gmail.com>
> 
> Reviewed-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>

Thanks!

~ Oleksii