[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 12/39] xen/riscv: save and restore vsiselect on vCPU context switch
- To: Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>
- From: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
- Date: Wed, 14 Oct 2026 16:53:06 +0200
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Romain Caritey <Romain.Caritey@xxxxxxxxxxxxx>, Zheng Zhang <zhangzheng@xxxxxxxxxxx>, Alistair Francis <alistair.francis@xxxxxxx>, Connor Davis <connojdavis@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
- Delivery-date: Wed, 14 Oct 2026 14:53:19 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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@xxxxxxxxx>
Reviewed-by: Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>
Thanks!
~ Oleksii
|
