On 3/11/26 10:54 AM, Oleksii Kurochko wrote:
On 3/10/26 10:15 AM, Jan Beulich wrote:
On 06.03.2026 17:33, Oleksii Kurochko wrote:
Some RISC-V platforms expose the SSTC extension, but its CSRs are not
properly saved and restored by Xen. Using SSTC in Xen could therefore
lead to unexpected behaviour.
And what's wrong with (or what gets in the way of) adding proper
saving/restoring? Also, wouldn't a guest use vstimecmp anyway? I.e. what
saving/restoring are you talking about here?
To avoid this in QEMU, disable SSTC by passing "sstc=off". On real
hardware, OpenSBI does not provide a mechanism to disable SSTC via the
DTS (riscv,isa or similar property), as it does not rely on that
property to determine extension availability. Instead, it directly
probes the CSR_STIMECMP register.
Introduce struct trap_info together with the do_expected_trap() handler
to safely probe CSRs. The helper csr_read_allowed() attempts to read a
CSR while catching traps, allowing Xen to detect whether the register
is accessible. This mechanism is used at boot to verify SSTC support
and
panic if the CSR is not available.
The trap handling infrastructure may also be reused for other cases
where controlled trap handling is required (e.g. probing instructions
such as HLV*).
Hmm, won't you need a more generic way of dealing with traps anyway? See
Linux'es _ASM_EXTABLE(). See also comments further down.
At the moment this approach works for me and I haven't had a need for
more
generic approach. I will look at _ASM_EXTABLE(). I haven't checked yet
but
I assume it will require some extra fixup code in trap handler what looks
like over complication for the current case, at least.
I checked _ASM_EXTABLE() implementation and so I will need basically provide
only
for now implementation of EX_TYPE_FIXUP what doesn't look too much and is
comparable
with the current suggested solution.
~ Oleksii
