Re: [PATCH v7 14/14] xen/riscv: Disable SSTC extension and add trap-based CSR probing

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

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