Introduce vtimer_set_timer() to program a vCPU’s virtual timer based on
guest-provided tick values. The function handles clearing pending timer
interrupts, converting ticks to nanoseconds, and correctly treating
(uint64_t)-1 as a request to disable the timer per the RISC-V SBI
specification.

Additionally, update vtimer_expired() to inject IRQ_VS_TIMER into
the target vCPU instead of panicking, enabling basic virtual timer
operation.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/riscv/include/asm/vtimer.h |  2 ++
 xen/arch/riscv/vtimer.c             | 30 ++++++++++++++++++++++++++++-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/include/asm/vtimer.h b/xen/arch/riscv/include/asm/vtimer.h
index a2ca704cf0cc..2cacaf74b83b 100644
--- a/xen/arch/riscv/include/asm/vtimer.h
+++ b/xen/arch/riscv/include/asm/vtimer.h
@@ -22,4 +22,6 @@ void vcpu_timer_destroy(struct vcpu *v);
 
 int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config);
 
+void vtimer_set_timer(struct vtimer *t, const uint64_t ticks);
+
 #endif /* ASM__RISCV__VTIMER_H */
diff --git a/xen/arch/riscv/vtimer.c b/xen/arch/riscv/vtimer.c
index 5ba533690bc2..99a0c5986f1d 100644
--- a/xen/arch/riscv/vtimer.c
+++ b/xen/arch/riscv/vtimer.c
@@ -1,6 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include <xen/domain.h>
 #include <xen/sched.h>
+#include <xen/time.h>
 
 #include <public/xen.h>
 
@@ -15,7 +17,9 @@ int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config)
 
 static void vtimer_expired(void *data)
 {
-    panic("%s: TBD\n", __func__);
+    struct vtimer *t = data;
+
+    vcpu_set_interrupt(t->v, IRQ_VS_TIMER);
 }
 
 int vcpu_vtimer_init(struct vcpu *v)
@@ -37,3 +41,27 @@ void vcpu_timer_destroy(struct vcpu *v)
 
     kill_timer(&v->arch.vtimer.timer);
 }
+
+void vtimer_set_timer(struct vtimer *t, const uint64_t ticks)
+{
+    s_time_t expires = ticks_to_ns(ticks - boot_clock_cycles);
+
+    vcpu_unset_interrupt(t->v, IRQ_VS_TIMER);
+
+    /*
+     * According to the RISC-V sbi spec:
+     *   If the supervisor wishes to clear the timer interrupt without
+     *   scheduling the next timer event, it can either request a timer
+     *   interrupt infinitely far into the future (i.e., (uint64_t)-1),
+     *   or it can instead mask the timer interrupt by clearing sie.STIE CSR
+     *   bit.
+     */
+    if ( ticks == ((uint64_t)~0ULL) )
+    {
+        stop_timer(&t->timer);
+
+        return;
+    }
+
+    set_timer(&t->timer, expires);
+}
-- 
2.52.0

On 24.12.2025 18:03, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/vtimer.h
> +++ b/xen/arch/riscv/include/asm/vtimer.h
> @@ -22,4 +22,6 @@ void vcpu_timer_destroy(struct vcpu *v);
>  
>  int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config);
>  
> +void vtimer_set_timer(struct vtimer *t, const uint64_t ticks);
> +
>  #endif /* ASM__RISCV__VTIMER_H */
> diff --git a/xen/arch/riscv/vtimer.c b/xen/arch/riscv/vtimer.c
> index 5ba533690bc2..99a0c5986f1d 100644
> --- a/xen/arch/riscv/vtimer.c
> +++ b/xen/arch/riscv/vtimer.c
> @@ -1,6 +1,8 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
>  
> +#include <xen/domain.h>

Is this really needed, when ...

>  #include <xen/sched.h>

... this is already there?

> +#include <xen/time.h>

Don't you mean xen/timer.h here?

> @@ -15,7 +17,9 @@ int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config)
>  
>  static void vtimer_expired(void *data)
>  {
> -    panic("%s: TBD\n", __func__);
> +    struct vtimer *t = data;

Pointer-to-const please.

> @@ -37,3 +41,27 @@ void vcpu_timer_destroy(struct vcpu *v)
>  
>      kill_timer(&v->arch.vtimer.timer);
>  }
> +
> +void vtimer_set_timer(struct vtimer *t, const uint64_t ticks)
> +{
> +    s_time_t expires = ticks_to_ns(ticks - boot_clock_cycles);

boot_clock_cycles is known to just Xen. If the guest provided input is an
absolute value, how would that work across migration? Doesn't there need
to be a guest-specific bias instead?

> +    vcpu_unset_interrupt(t->v, IRQ_VS_TIMER);
> +
> +    /*
> +     * According to the RISC-V sbi spec:
> +     *   If the supervisor wishes to clear the timer interrupt without
> +     *   scheduling the next timer event, it can either request a timer
> +     *   interrupt infinitely far into the future (i.e., (uint64_t)-1),
> +     *   or it can instead mask the timer interrupt by clearing sie.STIE CSR
> +     *   bit.
> +     */

And SBI is the only way to set the expiry value? No CSR access? (Question
also concerns the unconditional vcpu_unset_interrupt() above.)

> +    if ( ticks == ((uint64_t)~0ULL) )

Nit: With the cast you won't need the ULL suffix.

> +    {
> +        stop_timer(&t->timer);
> +
> +        return;
> +    }
> +
> +    set_timer(&t->timer, expires);

See the handling of VCPUOP_set_singleshot_timer for what you may want to
do if the expiry asked for is (perhaps just very slightly) into the past.
There you'll also find a use of migrate_timer(), which you will want to
at least consider using here as well.

Jan

On 1/8/26 11:28 AM, Jan Beulich wrote:
> On 24.12.2025 18:03, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/include/asm/vtimer.h
>> +++ b/xen/arch/riscv/include/asm/vtimer.h
>> @@ -22,4 +22,6 @@ void vcpu_timer_destroy(struct vcpu *v);
>>   
>>   int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config);
>>   
>> +void vtimer_set_timer(struct vtimer *t, const uint64_t ticks);
>> +
>>   #endif /* ASM__RISCV__VTIMER_H */
>> diff --git a/xen/arch/riscv/vtimer.c b/xen/arch/riscv/vtimer.c
>> index 5ba533690bc2..99a0c5986f1d 100644
>> --- a/xen/arch/riscv/vtimer.c
>> +++ b/xen/arch/riscv/vtimer.c
>> @@ -1,6 +1,8 @@
>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>   
>> +#include <xen/domain.h>
> Is this really needed, when ...
>
>>   #include <xen/sched.h>
> ... this is already there?

With the way how includes look in xen/sched.h - no.

>
>> +#include <xen/time.h>
> Don't you mean xen/timer.h here?

You are right, it should be xen/timer.h as set_timer(), stop_timer() and migrate_timer()
are from xen/timer.h.

>
>> @@ -15,7 +17,9 @@ int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config)
>>   
>>   static void vtimer_expired(void *data)
>>   {
>> -    panic("%s: TBD\n", __func__);
>> +    struct vtimer *t = data;
> Pointer-to-const please.
>
>> @@ -37,3 +41,27 @@ void vcpu_timer_destroy(struct vcpu *v)
>>   
>>       kill_timer(&v->arch.vtimer.timer);
>>   }
>> +
>> +void vtimer_set_timer(struct vtimer *t, const uint64_t ticks)
>> +{
>> +    s_time_t expires = ticks_to_ns(ticks - boot_clock_cycles);
> boot_clock_cycles is known to just Xen. If the guest provided input is an
> absolute value, how would that work across migration? Doesn't there need
> to be a guest-specific bias instead?

I think that I don't understand fully your questions, but it sounds like it is a job
for htimedelta register.

>
>> +    vcpu_unset_interrupt(t->v, IRQ_VS_TIMER);
>> +
>> +    /*
>> +     * According to the RISC-V sbi spec:
>> +     *   If the supervisor wishes to clear the timer interrupt without
>> +     *   scheduling the next timer event, it can either request a timer
>> +     *   interrupt infinitely far into the future (i.e., (uint64_t)-1),
>> +     *   or it can instead mask the timer interrupt by clearing sie.STIE CSR
>> +     *   bit.
>> +     */
> And SBI is the only way to set the expiry value? No CSR access? (Question
> also concerns the unconditional vcpu_unset_interrupt() above.)

If we don't have SSTC extension support then I suppose yes, as CSR_MI{E,P} could
be accessed only from M-mode:
  (code from OpenSBI)
void sbi_timer_event_start(u64 next_event)
{
	sbi_pmu_ctr_incr_fw(SBI_PMU_FW_SET_TIMER);

	/**
	 * Update the stimecmp directly if available. This allows
	 * the older software to leverage sstc extension on newer hardware.
	 */
	if (sbi_hart_has_extension(sbi_scratch_thishart_ptr(), SBI_HART_EXT_SSTC)) {
#if __riscv_xlen == 32
		csr_write(CSR_STIMECMP, next_event & 0xFFFFFFFF);
		csr_write(CSR_STIMECMPH, next_event >> 32);
#else
		csr_write(CSR_STIMECMP, next_event);
#endif
	} else if (timer_dev && timer_dev->timer_event_start) {
		timer_dev->timer_event_start(next_event);
		csr_clear(CSR_MIP, MIP_STIP);
	}
	csr_set(CSR_MIE, MIP_MTIP);
}

>
>> +    if ( ticks == ((uint64_t)~0ULL) )
> Nit: With the cast you won't need the ULL suffix.
>
>> +    {
>> +        stop_timer(&t->timer);
>> +
>> +        return;
>> +    }
>> +
>> +    set_timer(&t->timer, expires);
> See the handling of VCPUOP_set_singleshot_timer for what you may want to
> do if the expiry asked for is (perhaps just very slightly) into the past.

I got an idea why we want to check if "expires" already expired, but ...

> There you'll also find a use of migrate_timer(), which you will want to
> at least consider using here as well.

... I don't get why we want to migrate timer before set_timer() here.
Could you please explain that?

Thanks.

~ Oleksii

On 13.01.2026 15:44, Oleksii Kurochko wrote:
> On 1/8/26 11:28 AM, Jan Beulich wrote:
>> On 24.12.2025 18:03, Oleksii Kurochko wrote:
>>> @@ -15,7 +17,9 @@ int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config)
>>>   
>>>   static void vtimer_expired(void *data)
>>>   {
>>> -    panic("%s: TBD\n", __func__);
>>> +    struct vtimer *t = data;
>> Pointer-to-const please.
>>
>>> @@ -37,3 +41,27 @@ void vcpu_timer_destroy(struct vcpu *v)
>>>   
>>>       kill_timer(&v->arch.vtimer.timer);
>>>   }
>>> +
>>> +void vtimer_set_timer(struct vtimer *t, const uint64_t ticks)
>>> +{
>>> +    s_time_t expires = ticks_to_ns(ticks - boot_clock_cycles);
>> boot_clock_cycles is known to just Xen. If the guest provided input is an
>> absolute value, how would that work across migration? Doesn't there need
>> to be a guest-specific bias instead?
> 
> I think that I don't understand fully your questions, but it sounds like it is a job
> for htimedelta register.

Ah yes. As said, still learning RISC-V while reviewing your work.

>>> +    vcpu_unset_interrupt(t->v, IRQ_VS_TIMER);
>>> +
>>> +    /*
>>> +     * According to the RISC-V sbi spec:
>>> +     *   If the supervisor wishes to clear the timer interrupt without
>>> +     *   scheduling the next timer event, it can either request a timer
>>> +     *   interrupt infinitely far into the future (i.e., (uint64_t)-1),
>>> +     *   or it can instead mask the timer interrupt by clearing sie.STIE CSR
>>> +     *   bit.
>>> +     */
>> And SBI is the only way to set the expiry value? No CSR access? (Question
>> also concerns the unconditional vcpu_unset_interrupt() above.)
> 
> If we don't have SSTC extension support then I suppose yes, as CSR_MI{E,P} could
> be accessed only from M-mode:

How do M-mode CSRs come into play here? My question was rather towards ...

>   (code from OpenSBI)
> void sbi_timer_event_start(u64 next_event)
> {
> 	sbi_pmu_ctr_incr_fw(SBI_PMU_FW_SET_TIMER);
> 
> 	/**
> 	 * Update the stimecmp directly if available. This allows
> 	 * the older software to leverage sstc extension on newer hardware.
> 	 */
> 	if (sbi_hart_has_extension(sbi_scratch_thishart_ptr(), SBI_HART_EXT_SSTC)) {
> #if __riscv_xlen == 32
> 		csr_write(CSR_STIMECMP, next_event & 0xFFFFFFFF);
> 		csr_write(CSR_STIMECMPH, next_event >> 32);
> #else
> 		csr_write(CSR_STIMECMP, next_event);
> #endif

... what if a guest did these CSR writes directly. Besides intercepting
access to them, you'd also need to synchronize both paths, I suppose.

>>> +    {
>>> +        stop_timer(&t->timer);
>>> +
>>> +        return;
>>> +    }
>>> +
>>> +    set_timer(&t->timer, expires);
>> See the handling of VCPUOP_set_singleshot_timer for what you may want to
>> do if the expiry asked for is (perhaps just very slightly) into the past.
> 
> I got an idea why we want to check if "expires" already expired, but ...
> 
>> There you'll also find a use of migrate_timer(), which you will want to
>> at least consider using here as well.
> 
> ... I don't get why we want to migrate timer before set_timer() here.
> Could you please explain that?

Didn't I see you use migrate_timer() in other patches (making me assume
you understand)? Having the timer tied to the pCPU where the vCPU runs
means the signalling to that vCPU will (commonly) be cheaper. Whether
that actually matters depends on what vtimer_expired() will eventually
contain. Hence why I said "consider using".

Jan

On 1/13/26 4:12 PM, Jan Beulich wrote:
> On 13.01.2026 15:44, Oleksii Kurochko wrote:
>> On 1/8/26 11:28 AM, Jan Beulich wrote:
>>> On 24.12.2025 18:03, Oleksii Kurochko wrote:
>>>> +    vcpu_unset_interrupt(t->v, IRQ_VS_TIMER);
>>>> +
>>>> +    /*
>>>> +     * According to the RISC-V sbi spec:
>>>> +     *   If the supervisor wishes to clear the timer interrupt without
>>>> +     *   scheduling the next timer event, it can either request a timer
>>>> +     *   interrupt infinitely far into the future (i.e., (uint64_t)-1),
>>>> +     *   or it can instead mask the timer interrupt by clearing sie.STIE CSR
>>>> +     *   bit.
>>>> +     */
>>> And SBI is the only way to set the expiry value? No CSR access? (Question
>>> also concerns the unconditional vcpu_unset_interrupt() above.)
>> If we don't have SSTC extension support then I suppose yes, as CSR_MI{E,P} could
>> be accessed only from M-mode:
> How do M-mode CSRs come into play here? My question was rather towards ...

Without SSTC (Supervisor Timer Extension) the current Privileged arch specification
only defines a hardware mechanism for generating machine-mode timer interrupts (based
on the mtime and mtimecmp registers). With the resultant requirement that timer
services for S-mode/HS-mode (and for VS-mode) have to all be provided by M-mode - via
SBI calls from S/HS-mode up to M-mode (or VS-mode calls to HS-mode and then to M-mode).

>
>>    (code from OpenSBI)
>> void sbi_timer_event_start(u64 next_event)
>> {
>> 	sbi_pmu_ctr_incr_fw(SBI_PMU_FW_SET_TIMER);
>>
>> 	/**
>> 	 * Update the stimecmp directly if available. This allows
>> 	 * the older software to leverage sstc extension on newer hardware.
>> 	 */
>> 	if (sbi_hart_has_extension(sbi_scratch_thishart_ptr(), SBI_HART_EXT_SSTC)) {
>> #if __riscv_xlen == 32
>> 		csr_write(CSR_STIMECMP, next_event & 0xFFFFFFFF);
>> 		csr_write(CSR_STIMECMPH, next_event >> 32);
>> #else
>> 		csr_write(CSR_STIMECMP, next_event);
>> #endif
> ... what if a guest did these CSR writes directly. Besides intercepting
> access to them,

These registers are available only when the SSTC extension is present.
When SSTC is available and a guest accesses CSR_STIMECMP{H}, it actually
accesses the corresponding VS aliases, VSTIMECMP{H}. The hardware continuously
compares the value in VSTIMECMP against the guest’s view of time
(time + htimedelta). When the condition is met, the hardware asserts the
virtual supervisor timer interrupt pending bit (VSTIP) in the hypervisor’s
HIP register and guest automatically receives timer interrupt.

Therefore, there is no real need to intercept accesses to these registers.

It is possible that VS-mode software may continue to use the SBI timer call
instead of directly accessing the SSTC CSRs. In that case, VSTIMECMP would
need to be updated manually by the hypervisor when such an SBI call occurs.
However, this is not the case at the moment, as the SSTC extension is not
currently supported.

Technically, the hypervisor could also clear henvcfg.STCE when SSTC is
vailable. In that case, the hypervisor would receive an illegal
instruction trap in HS-mode when the guest attempts to access SSTC-related
registers.
However, I do not see a reason to prevent delegation of SSTC register access
to the guest, since SSTC provides VS-* aliases for these registers, so I don't
consider that as a real case.


> you'd also need to synchronize both paths, I suppose.

I didn't get you what is needed to be synchronized. Could you please explain?


>
>>>> +    {
>>>> +        stop_timer(&t->timer);
>>>> +
>>>> +        return;
>>>> +    }
>>>> +
>>>> +    set_timer(&t->timer, expires);
>>> See the handling of VCPUOP_set_singleshot_timer for what you may want to
>>> do if the expiry asked for is (perhaps just very slightly) into the past.
>> I got an idea why we want to check if "expires" already expired, but ...
>>
>>> There you'll also find a use of migrate_timer(), which you will want to
>>> at least consider using here as well.
>> ... I don't get why we want to migrate timer before set_timer() here.
>> Could you please explain that?
> Didn't I see you use migrate_timer() in other patches (making me assume
> you understand)? Having the timer tied to the pCPU where the vCPU runs
> means the signalling to that vCPU will (commonly) be cheaper.

I thought that migrate_timer() is needed only when a vCPU changes the pCPU
it is running on to ensure that it is running on correct pCPU after migrations,
hotplug events, or scheduling changes. That is why I placed it in
vtimer_restore(), as there is no guarantee that the vCPU will run on the
same pCPU it was running on previously.

So that is why ...

> Whether
> that actually matters depends on what vtimer_expired() will eventually
> contain. Hence why I said "consider using".

... I didn't get why I might need vtimer_expired() in vtimer_set_timer()
before set_timer().

vtimer_expired() will only notify the vCPU that a timer interrupt has
occurred by setting bit in irqs_pending bitmap which then will be synced
with vcpu->hvip, but I still do not understand whether migrate_timer()
is needed before calling set_timer() here.

Considering that vtimer_set_timer() is called from the vCPU while it is
running on the current pCPU, and assuming no pCPU rescheduling has
occurred for this vCPU, we are already on the correct pCPU.
If pCPU rescheduling for the vCPU did occur, then migrate_timer() would
have been called in context_switch(), and at the point where
vtimer_set_timer() is invoked, we would already be running on the
correct pCPU.

~ Oleksii

On 14.01.2026 13:27, Oleksii Kurochko wrote:
> On 1/13/26 4:12 PM, Jan Beulich wrote:
>> On 13.01.2026 15:44, Oleksii Kurochko wrote:
>>> On 1/8/26 11:28 AM, Jan Beulich wrote:
>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote:
> Therefore, there is no real need to intercept accesses to these registers.

With this ...

>> you'd also need to synchronize both paths, I suppose.
> 
> I didn't get you what is needed to be synchronized. Could you please explain?

... there's nothing to synchronize.

>>>>> +    {
>>>>> +        stop_timer(&t->timer);
>>>>> +
>>>>> +        return;
>>>>> +    }
>>>>> +
>>>>> +    set_timer(&t->timer, expires);
>>>> See the handling of VCPUOP_set_singleshot_timer for what you may want to
>>>> do if the expiry asked for is (perhaps just very slightly) into the past.
>>> I got an idea why we want to check if "expires" already expired, but ...
>>>
>>>> There you'll also find a use of migrate_timer(), which you will want to
>>>> at least consider using here as well.
>>> ... I don't get why we want to migrate timer before set_timer() here.
>>> Could you please explain that?
>> Didn't I see you use migrate_timer() in other patches (making me assume
>> you understand)? Having the timer tied to the pCPU where the vCPU runs
>> means the signalling to that vCPU will (commonly) be cheaper.
> 
> I thought that migrate_timer() is needed only when a vCPU changes the pCPU
> it is running on to ensure that it is running on correct pCPU after migrations,
> hotplug events, or scheduling changes. That is why I placed it in
> vtimer_restore(), as there is no guarantee that the vCPU will run on the
> same pCPU it was running on previously.
> 
> So that is why ...
> 
>> Whether
>> that actually matters depends on what vtimer_expired() will eventually
>> contain. Hence why I said "consider using".
> 
> ... I didn't get why I might need vtimer_expired() in vtimer_set_timer()
> before set_timer().
> 
> vtimer_expired() will only notify the vCPU that a timer interrupt has
> occurred by setting bit in irqs_pending bitmap which then will be synced
> with vcpu->hvip, but I still do not understand whether migrate_timer()
> is needed before calling set_timer() here.

Just to repeat - it's not needed. It may be wanted.

> Considering that vtimer_set_timer() is called from the vCPU while it is
> running on the current pCPU, and assuming no pCPU rescheduling has
> occurred for this vCPU, we are already on the correct pCPU.
> If pCPU rescheduling for the vCPU did occur, then migrate_timer() would
> have been called in context_switch(),

Even if the timer wasn't active?

Jan

> and at the point where
> vtimer_set_timer() is invoked, we would already be running on the
> correct pCPU.
> 
> ~ Oleksii
>

On 1/14/26 3:57 PM, Jan Beulich wrote:
> On 14.01.2026 13:27, Oleksii Kurochko wrote:
>> On 1/13/26 4:12 PM, Jan Beulich wrote:
>>> On 13.01.2026 15:44, Oleksii Kurochko wrote:
>>>> On 1/8/26 11:28 AM, Jan Beulich wrote:
>>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote:
>>>>>> +    {
>>>>>> +        stop_timer(&t->timer);
>>>>>> +
>>>>>> +        return;
>>>>>> +    }
>>>>>> +
>>>>>> +    set_timer(&t->timer, expires);
>>>>> See the handling of VCPUOP_set_singleshot_timer for what you may want to
>>>>> do if the expiry asked for is (perhaps just very slightly) into the past.
>>>> I got an idea why we want to check if "expires" already expired, but ...
>>>>
>>>>> There you'll also find a use of migrate_timer(), which you will want to
>>>>> at least consider using here as well.
>>>> ... I don't get why we want to migrate timer before set_timer() here.
>>>> Could you please explain that?
>>> Didn't I see you use migrate_timer() in other patches (making me assume
>>> you understand)? Having the timer tied to the pCPU where the vCPU runs
>>> means the signalling to that vCPU will (commonly) be cheaper.
>> I thought that migrate_timer() is needed only when a vCPU changes the pCPU
>> it is running on to ensure that it is running on correct pCPU after migrations,
>> hotplug events, or scheduling changes. That is why I placed it in
>> vtimer_restore(), as there is no guarantee that the vCPU will run on the
>> same pCPU it was running on previously.
>>
>> So that is why ...
>>
>>> Whether
>>> that actually matters depends on what vtimer_expired() will eventually
>>> contain. Hence why I said "consider using".
>> ... I didn't get why I might need vtimer_expired() in vtimer_set_timer()
>> before set_timer().
>>
>> vtimer_expired() will only notify the vCPU that a timer interrupt has
>> occurred by setting bit in irqs_pending bitmap which then will be synced
>> with vcpu->hvip, but I still do not understand whether migrate_timer()
>> is needed before calling set_timer() here.
> Just to repeat - it's not needed. It may be wanted.
>
>> Considering that vtimer_set_timer() is called from the vCPU while it is
>> running on the current pCPU, and assuming no pCPU rescheduling has
>> occurred for this vCPU, we are already on the correct pCPU.
>> If pCPU rescheduling for the vCPU did occur, then migrate_timer() would
>> have been called in context_switch(),
> Even if the timer wasn't active?

Yes, migrate_timer() is called unconditionally in vtimer_restore() called
from context_switch(). migrate_timer() will activate the timer.

~ Oleksii

>> and at the point where
>> vtimer_set_timer() is invoked, we would already be running on the
>> correct pCPU.
>>
>> ~ Oleksii
>>

On 14.01.2026 16:59, Oleksii Kurochko wrote:
> 
> On 1/14/26 3:57 PM, Jan Beulich wrote:
>> On 14.01.2026 13:27, Oleksii Kurochko wrote:
>>> On 1/13/26 4:12 PM, Jan Beulich wrote:
>>>> On 13.01.2026 15:44, Oleksii Kurochko wrote:
>>>>> On 1/8/26 11:28 AM, Jan Beulich wrote:
>>>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote:
>>>>>>> +    {
>>>>>>> +        stop_timer(&t->timer);
>>>>>>> +
>>>>>>> +        return;
>>>>>>> +    }
>>>>>>> +
>>>>>>> +    set_timer(&t->timer, expires);
>>>>>> See the handling of VCPUOP_set_singleshot_timer for what you may want to
>>>>>> do if the expiry asked for is (perhaps just very slightly) into the past.
>>>>> I got an idea why we want to check if "expires" already expired, but ...
>>>>>
>>>>>> There you'll also find a use of migrate_timer(), which you will want to
>>>>>> at least consider using here as well.
>>>>> ... I don't get why we want to migrate timer before set_timer() here.
>>>>> Could you please explain that?
>>>> Didn't I see you use migrate_timer() in other patches (making me assume
>>>> you understand)? Having the timer tied to the pCPU where the vCPU runs
>>>> means the signalling to that vCPU will (commonly) be cheaper.
>>> I thought that migrate_timer() is needed only when a vCPU changes the pCPU
>>> it is running on to ensure that it is running on correct pCPU after migrations,
>>> hotplug events, or scheduling changes. That is why I placed it in
>>> vtimer_restore(), as there is no guarantee that the vCPU will run on the
>>> same pCPU it was running on previously.
>>>
>>> So that is why ...
>>>
>>>> Whether
>>>> that actually matters depends on what vtimer_expired() will eventually
>>>> contain. Hence why I said "consider using".
>>> ... I didn't get why I might need vtimer_expired() in vtimer_set_timer()
>>> before set_timer().
>>>
>>> vtimer_expired() will only notify the vCPU that a timer interrupt has
>>> occurred by setting bit in irqs_pending bitmap which then will be synced
>>> with vcpu->hvip, but I still do not understand whether migrate_timer()
>>> is needed before calling set_timer() here.
>> Just to repeat - it's not needed. It may be wanted.
>>
>>> Considering that vtimer_set_timer() is called from the vCPU while it is
>>> running on the current pCPU, and assuming no pCPU rescheduling has
>>> occurred for this vCPU, we are already on the correct pCPU.
>>> If pCPU rescheduling for the vCPU did occur, then migrate_timer() would
>>> have been called in context_switch(),
>> Even if the timer wasn't active?
> 
> Yes, migrate_timer() is called unconditionally in vtimer_restore() called
> from context_switch(). migrate_timer() will activate the timer.

Which is wrong?

Jan

On 1/15/26 8:52 AM, Jan Beulich wrote:
> On 14.01.2026 16:59, Oleksii Kurochko wrote:
>> On 1/14/26 3:57 PM, Jan Beulich wrote:
>>> On 14.01.2026 13:27, Oleksii Kurochko wrote:
>>>> On 1/13/26 4:12 PM, Jan Beulich wrote:
>>>>> On 13.01.2026 15:44, Oleksii Kurochko wrote:
>>>>>> On 1/8/26 11:28 AM, Jan Beulich wrote:
>>>>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote:
>>>>>>>> +    {
>>>>>>>> +        stop_timer(&t->timer);
>>>>>>>> +
>>>>>>>> +        return;
>>>>>>>> +    }
>>>>>>>> +
>>>>>>>> +    set_timer(&t->timer, expires);
>>>>>>> See the handling of VCPUOP_set_singleshot_timer for what you may want to
>>>>>>> do if the expiry asked for is (perhaps just very slightly) into the past.
>>>>>> I got an idea why we want to check if "expires" already expired, but ...
>>>>>>
>>>>>>> There you'll also find a use of migrate_timer(), which you will want to
>>>>>>> at least consider using here as well.
>>>>>> ... I don't get why we want to migrate timer before set_timer() here.
>>>>>> Could you please explain that?
>>>>> Didn't I see you use migrate_timer() in other patches (making me assume
>>>>> you understand)? Having the timer tied to the pCPU where the vCPU runs
>>>>> means the signalling to that vCPU will (commonly) be cheaper.
>>>> I thought that migrate_timer() is needed only when a vCPU changes the pCPU
>>>> it is running on to ensure that it is running on correct pCPU after migrations,
>>>> hotplug events, or scheduling changes. That is why I placed it in
>>>> vtimer_restore(), as there is no guarantee that the vCPU will run on the
>>>> same pCPU it was running on previously.
>>>>
>>>> So that is why ...
>>>>
>>>>> Whether
>>>>> that actually matters depends on what vtimer_expired() will eventually
>>>>> contain. Hence why I said "consider using".
>>>> ... I didn't get why I might need vtimer_expired() in vtimer_set_timer()
>>>> before set_timer().
>>>>
>>>> vtimer_expired() will only notify the vCPU that a timer interrupt has
>>>> occurred by setting bit in irqs_pending bitmap which then will be synced
>>>> with vcpu->hvip, but I still do not understand whether migrate_timer()
>>>> is needed before calling set_timer() here.
>>> Just to repeat - it's not needed. It may be wanted.
>>>
>>>> Considering that vtimer_set_timer() is called from the vCPU while it is
>>>> running on the current pCPU, and assuming no pCPU rescheduling has
>>>> occurred for this vCPU, we are already on the correct pCPU.
>>>> If pCPU rescheduling for the vCPU did occur, then migrate_timer() would
>>>> have been called in context_switch(),
>>> Even if the timer wasn't active?
>> Yes, migrate_timer() is called unconditionally in vtimer_restore() called
>> from context_switch(). migrate_timer() will activate the timer.
> Which is wrong?

I don't know, based on the comment above migrate_timer():
   /* Migrate a timer to a different CPU. The timer may be currently active. */

it doesn't mention that it shouldn't be called if the timer wasn't active.
All around other cases where migrate_timer() is used I don't see also that
anyone checks if a timer is active or not.

~ Oleksii

On 15.01.2026 10:30, Oleksii Kurochko wrote:
> 
> On 1/15/26 8:52 AM, Jan Beulich wrote:
>> On 14.01.2026 16:59, Oleksii Kurochko wrote:
>>> On 1/14/26 3:57 PM, Jan Beulich wrote:
>>>> On 14.01.2026 13:27, Oleksii Kurochko wrote:
>>>>> On 1/13/26 4:12 PM, Jan Beulich wrote:
>>>>>> On 13.01.2026 15:44, Oleksii Kurochko wrote:
>>>>>>> On 1/8/26 11:28 AM, Jan Beulich wrote:
>>>>>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote:
>>>>>>>>> +    {
>>>>>>>>> +        stop_timer(&t->timer);
>>>>>>>>> +
>>>>>>>>> +        return;
>>>>>>>>> +    }
>>>>>>>>> +
>>>>>>>>> +    set_timer(&t->timer, expires);
>>>>>>>> See the handling of VCPUOP_set_singleshot_timer for what you may want to
>>>>>>>> do if the expiry asked for is (perhaps just very slightly) into the past.
>>>>>>> I got an idea why we want to check if "expires" already expired, but ...
>>>>>>>
>>>>>>>> There you'll also find a use of migrate_timer(), which you will want to
>>>>>>>> at least consider using here as well.
>>>>>>> ... I don't get why we want to migrate timer before set_timer() here.
>>>>>>> Could you please explain that?
>>>>>> Didn't I see you use migrate_timer() in other patches (making me assume
>>>>>> you understand)? Having the timer tied to the pCPU where the vCPU runs
>>>>>> means the signalling to that vCPU will (commonly) be cheaper.
>>>>> I thought that migrate_timer() is needed only when a vCPU changes the pCPU
>>>>> it is running on to ensure that it is running on correct pCPU after migrations,
>>>>> hotplug events, or scheduling changes. That is why I placed it in
>>>>> vtimer_restore(), as there is no guarantee that the vCPU will run on the
>>>>> same pCPU it was running on previously.
>>>>>
>>>>> So that is why ...
>>>>>
>>>>>> Whether
>>>>>> that actually matters depends on what vtimer_expired() will eventually
>>>>>> contain. Hence why I said "consider using".
>>>>> ... I didn't get why I might need vtimer_expired() in vtimer_set_timer()
>>>>> before set_timer().
>>>>>
>>>>> vtimer_expired() will only notify the vCPU that a timer interrupt has
>>>>> occurred by setting bit in irqs_pending bitmap which then will be synced
>>>>> with vcpu->hvip, but I still do not understand whether migrate_timer()
>>>>> is needed before calling set_timer() here.
>>>> Just to repeat - it's not needed. It may be wanted.
>>>>
>>>>> Considering that vtimer_set_timer() is called from the vCPU while it is
>>>>> running on the current pCPU, and assuming no pCPU rescheduling has
>>>>> occurred for this vCPU, we are already on the correct pCPU.
>>>>> If pCPU rescheduling for the vCPU did occur, then migrate_timer() would
>>>>> have been called in context_switch(),
>>>> Even if the timer wasn't active?
>>> Yes, migrate_timer() is called unconditionally in vtimer_restore() called
>>> from context_switch(). migrate_timer() will activate the timer.
>> Which is wrong?
> 
> I don't know, based on the comment above migrate_timer():
>    /* Migrate a timer to a different CPU. The timer may be currently active. */
> 
> it doesn't mention that it shouldn't be called if the timer wasn't active.
> All around other cases where migrate_timer() is used I don't see also that
> anyone checks if a timer is active or not.

Hmm, I'm sorry, I was mis-remembering. Migrating is indeed fine for inactive
timers.

Jan