Re: [PATCH v3 13/16] xen/riscv: implement reprogram_timer() via SBI

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.02.2026 16:12, Jan Beulich wrote:
> On 09.02.2026 17:52, Oleksii Kurochko wrote:
>> Implement reprogram_timer() on RISC-V using the standard SBI timer call.
>>
>> The privileged architecture only defines machine-mode timer interrupts
>> (using mtime/mtimecmp). Therefore, timer services for S/HS/VS mode must
>> be provided by M-mode via SBI calls. SSTC (Supervisor-mode Timer Control)
>> is optional and is not supported on the boards available to me, so the
>> only viable approach today is to program the timer through SBI.
>>
>> reprogram_timer() enables/disables the supervisor timer interrupt and
>> programs the next timer deadline using sbi_set_timer(). If the SBI call
>> fails, the code panics, because sbi_set_timer() is expected to return
>> either 0 or -ENOSUPP (this has been stable from early OpenSBI versions to
>> the latest ones). The SBI spec does not define a standard negative error
>> code for this call, and without SSTC there is no alternative method to
>> program the timer, so the SBI timer call must be available.
>>
>> reprogram_timer() currently returns int for compatibility with the
>> existing prototype. While it might be cleaner to return bool, keeping the
>> existing signature avoids premature changes in case sbi_set_timer() ever
>> needs to return other values (based on which we could try to avoid
>> panic-ing) in the future.
>>
>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
> 
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
>> ---
>> Changes in v3:
>>  - Correct the comments in reprogram_timer().
>>  - Move enablement of timer interrupt after sbi_set_timer() to avoid
>>    potentially receiving a timer interrupt between these 2 operations.
> 
> I'd like to mention that this is of only hypothetical concern, at least for
> the sole caller in common code: That's doing the call with IRQs off, so
> only the bit in SIP could become set too early, while no IRQ would surface
> before timer_softirq_action() turns IRQs on again.

Actually, further to this: If IRQs were on, an IRQ could still surface
between the two operations, when the SIE bit was already sent upon entry
into the function (i.e. for example when a timeout is being moved earlier).

Jan