The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [PATCH] LoongArch: KVM: Reload one-shot TVAL on migration destination
@ 2026-07-15  3:28 Tao Cui
  2026-07-15  3:49 ` Bibo Mao
  0 siblings, 1 reply; 4+ messages in thread
From: Tao Cui @ 2026-07-15  3:28 UTC (permalink / raw)
  To: zhaotianrui, maobibo
  Cc: chenhuacai, kernel, kvm, loongarch, linux-kernel, lixianglai,
	cuitao, cui.tao

From: Tao Cui <cuitao@kylinos.cn>

kvm_restore_timer() rebuilds the remaining timer countdown from
vcpu->arch.expire, which is host-internal and is not part of the migrated
vCPU state. On the migration destination it is still 0, so for a one-shot
timer that has not expired yet the computed delta is 0 and
write_gcsr_timertick(0) injects the timer interrupt immediately instead of
after the remaining time. The guest observes a premature timer event right
after migration.

The expired one-shot case (TVAL = -1) is already handled earlier, so only
the non-expired one-shot path is affected. When expire has not been set
(i.e. on the destination), reload the remaining countdown from the
migrated TVAL. The regular preempt/resume path on the source, where
expire is valid, is unchanged.

Fixes: a5857b9ff6e0 ("LoongArch: KVM: Implement vcpu timer operations")
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
---
 arch/loongarch/kvm/timer.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/loongarch/kvm/timer.c b/arch/loongarch/kvm/timer.c
index 3829f35a4070..57f53d19a00a 100644
--- a/arch/loongarch/kvm/timer.c
+++ b/arch/loongarch/kvm/timer.c
@@ -132,6 +132,14 @@ void kvm_restore_timer(struct kvm_vcpu *vcpu)
 		 * during injecting intr async
 		 */
 		kvm_queue_irq(vcpu, INT_TI);
+	} else if (!expire) {
+		/*
+		 * One-shot timer on the migration destination: vcpu->arch.expire
+		 * is host-internal and is not migrated, so it is still 0 here.
+		 * Reload the remaining countdown from the migrated TVAL instead
+		 * of firing the timer immediately.
+		 */
+		delta = ticks;
 	}
 
 	write_gcsr_timertick(delta);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] LoongArch: KVM: Reload one-shot TVAL on migration destination
  2026-07-15  3:28 [PATCH] LoongArch: KVM: Reload one-shot TVAL on migration destination Tao Cui
@ 2026-07-15  3:49 ` Bibo Mao
  2026-07-15  5:53   ` Tao Cui
  0 siblings, 1 reply; 4+ messages in thread
From: Bibo Mao @ 2026-07-15  3:49 UTC (permalink / raw)
  To: Tao Cui, zhaotianrui
  Cc: chenhuacai, kernel, kvm, loongarch, linux-kernel, lixianglai,
	cuitao



On 2026/7/15 上午11:28, Tao Cui wrote:
> From: Tao Cui <cuitao@kylinos.cn>
> 
> kvm_restore_timer() rebuilds the remaining timer countdown from
> vcpu->arch.expire, which is host-internal and is not part of the migrated
> vCPU state. On the migration destination it is still 0, so for a one-shot
> timer that has not expired yet the computed delta is 0 and
> write_gcsr_timertick(0) injects the timer interrupt immediately instead of
> after the remaining time. The guest observes a premature timer event right
> after migration.
> 
> The expired one-shot case (TVAL = -1) is already handled earlier, so only
> the non-expired one-shot path is affected. When expire has not been set
> (i.e. on the destination), reload the remaining countdown from the
> migrated TVAL. The regular preempt/resume path on the source, where
> expire is valid, is unchanged.
> 
> Fixes: a5857b9ff6e0 ("LoongArch: KVM: Implement vcpu timer operations")
> Signed-off-by: Tao Cui <cuitao@kylinos.cn>
> ---
>   arch/loongarch/kvm/timer.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/arch/loongarch/kvm/timer.c b/arch/loongarch/kvm/timer.c
> index 3829f35a4070..57f53d19a00a 100644
> --- a/arch/loongarch/kvm/timer.c
> +++ b/arch/loongarch/kvm/timer.c
> @@ -132,6 +132,14 @@ void kvm_restore_timer(struct kvm_vcpu *vcpu)
>   		 * during injecting intr async
>   		 */
>   		kvm_queue_irq(vcpu, INT_TI);
> +	} else if (!expire) {
> +		/*
> +		 * One-shot timer on the migration destination: vcpu->arch.expire
> +		 * is host-internal and is not migrated, so it is still 0 here.
Good catch, I ever noticed this issue before however without good 
method. My previous method is to recalculate vcpu->arch.expire in 
function _kvm_setcsr() when LOONGARCH_CSR_TVAL is set and value of 
vcpu->arch.expire is 0.

Regards
Bibo Mao
> +		 * Reload the remaining countdown from the migrated TVAL instead
> +		 * of firing the timer immediately.
> +		 */
> +		delta = ticks;
>   	}
>   
>   	write_gcsr_timertick(delta);
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] LoongArch: KVM: Reload one-shot TVAL on migration destination
  2026-07-15  3:49 ` Bibo Mao
@ 2026-07-15  5:53   ` Tao Cui
  2026-07-15  6:21     ` Bibo Mao
  0 siblings, 1 reply; 4+ messages in thread
From: Tao Cui @ 2026-07-15  5:53 UTC (permalink / raw)
  To: Bibo Mao, zhaotianrui
  Cc: cui.tao, chenhuacai, kernel, kvm, loongarch, linux-kernel,
	lixianglai, cuitao



在 2026/7/15 11:49, Bibo Mao 写道:
> 
> 
> On 2026/7/15 上午11:28, Tao Cui wrote:
>> From: Tao Cui <cuitao@kylinos.cn>
>>
>> kvm_restore_timer() rebuilds the remaining timer countdown from
>> vcpu->arch.expire, which is host-internal and is not part of the migrated
>> vCPU state. On the migration destination it is still 0, so for a one-shot
>> timer that has not expired yet the computed delta is 0 and
>> write_gcsr_timertick(0) injects the timer interrupt immediately instead of
>> after the remaining time. The guest observes a premature timer event right
>> after migration.
>>
>> The expired one-shot case (TVAL = -1) is already handled earlier, so only
>> the non-expired one-shot path is affected. When expire has not been set
>> (i.e. on the destination), reload the remaining countdown from the
>> migrated TVAL. The regular preempt/resume path on the source, where
>> expire is valid, is unchanged.
>>
>> Fixes: a5857b9ff6e0 ("LoongArch: KVM: Implement vcpu timer operations")
>> Signed-off-by: Tao Cui <cuitao@kylinos.cn>
>> ---
>>   arch/loongarch/kvm/timer.c | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/loongarch/kvm/timer.c b/arch/loongarch/kvm/timer.c
>> index 3829f35a4070..57f53d19a00a 100644
>> --- a/arch/loongarch/kvm/timer.c
>> +++ b/arch/loongarch/kvm/timer.c
>> @@ -132,6 +132,14 @@ void kvm_restore_timer(struct kvm_vcpu *vcpu)
>>            * during injecting intr async
>>            */
>>           kvm_queue_irq(vcpu, INT_TI);
>> +    } else if (!expire) {
>> +        /*
>> +         * One-shot timer on the migration destination: vcpu->arch.expire
>> +         * is host-internal and is not migrated, so it is still 0 here.
> Good catch, I ever noticed this issue before however without good method. My previous method is to recalculate vcpu->arch.expire in function _kvm_setcsr() when LOONGARCH_CSR_TVAL is set and value of vcpu->arch.expire is 0.
> 
Thanks for the review and for sharing your idea. I also considered
recalculating expire in _kvm_setcsr() when TVAL is restored, but ended
up keeping the change within kvm_restore_timer() to avoid touching the
core CSR write path. Both approaches are functionally equivalent since
the first save_timer() after restore will set expire correctly either
way.

That said, if you prefer the _kvm_setcsr() approach, I'm happy to
rework the patch accordingly.

Thanks,
Tao
> Regards
> Bibo Mao
>> +         * Reload the remaining countdown from the migrated TVAL instead
>> +         * of firing the timer immediately.
>> +         */
>> +        delta = ticks;
>>       }
>>         write_gcsr_timertick(delta);
>>
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] LoongArch: KVM: Reload one-shot TVAL on migration destination
  2026-07-15  5:53   ` Tao Cui
@ 2026-07-15  6:21     ` Bibo Mao
  0 siblings, 0 replies; 4+ messages in thread
From: Bibo Mao @ 2026-07-15  6:21 UTC (permalink / raw)
  To: Tao Cui, zhaotianrui
  Cc: chenhuacai, kernel, kvm, loongarch, linux-kernel, lixianglai,
	cuitao



On 2026/7/15 下午1:53, Tao Cui wrote:
> 
> 
> 在 2026/7/15 11:49, Bibo Mao 写道:
>>
>>
>> On 2026/7/15 上午11:28, Tao Cui wrote:
>>> From: Tao Cui <cuitao@kylinos.cn>
>>>
>>> kvm_restore_timer() rebuilds the remaining timer countdown from
>>> vcpu->arch.expire, which is host-internal and is not part of the migrated
>>> vCPU state. On the migration destination it is still 0, so for a one-shot
>>> timer that has not expired yet the computed delta is 0 and
>>> write_gcsr_timertick(0) injects the timer interrupt immediately instead of
>>> after the remaining time. The guest observes a premature timer event right
>>> after migration.
>>>
>>> The expired one-shot case (TVAL = -1) is already handled earlier, so only
>>> the non-expired one-shot path is affected. When expire has not been set
>>> (i.e. on the destination), reload the remaining countdown from the
>>> migrated TVAL. The regular preempt/resume path on the source, where
>>> expire is valid, is unchanged.
>>>
>>> Fixes: a5857b9ff6e0 ("LoongArch: KVM: Implement vcpu timer operations")
>>> Signed-off-by: Tao Cui <cuitao@kylinos.cn>
>>> ---
>>>    arch/loongarch/kvm/timer.c | 8 ++++++++
>>>    1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/loongarch/kvm/timer.c b/arch/loongarch/kvm/timer.c
>>> index 3829f35a4070..57f53d19a00a 100644
>>> --- a/arch/loongarch/kvm/timer.c
>>> +++ b/arch/loongarch/kvm/timer.c
>>> @@ -132,6 +132,14 @@ void kvm_restore_timer(struct kvm_vcpu *vcpu)
>>>             * during injecting intr async
>>>             */
>>>            kvm_queue_irq(vcpu, INT_TI);
>>> +    } else if (!expire) {
>>> +        /*
>>> +         * One-shot timer on the migration destination: vcpu->arch.expire
>>> +         * is host-internal and is not migrated, so it is still 0 here.
>> Good catch, I ever noticed this issue before however without good method. My previous method is to recalculate vcpu->arch.expire in function _kvm_setcsr() when LOONGARCH_CSR_TVAL is set and value of vcpu->arch.expire is 0.
>>
> Thanks for the review and for sharing your idea. I also considered
> recalculating expire in _kvm_setcsr() when TVAL is restored, but ended
> up keeping the change within kvm_restore_timer() to avoid touching the
> core CSR write path. Both approaches are functionally equivalent since
> the first save_timer() after restore will set expire correctly either
> way.
> 
> That said, if you prefer the _kvm_setcsr() approach, I'm happy to
The problem in _kvm_setcsr() is that there is only register 
LOONGARCH_CSR_TVAL however no context of LOONGARCH_CSR_TCFG register, it 
seems that it is better in to restore it in kvm_restore_timer() function 
where all registers about CPU timer are set.

How about something like this, it should work with period timer mode 
when migration.
@@ -119,6 +119,17 @@ void kvm_restore_timer(struct kvm_vcpu *vcpu)
         delta = 0;
         now = ktime_get();
         expire = vcpu->arch.expire;
+       if (!expire) {
+             /*
+              * The field vcpu->arch.expire is host-internal and is not
+              * migrated, so it is 0 after migration. Reload the
+              * remaining countdown from the migrated TVAL.
+              */
+               if (ticks < cfg)
+                       delta = tick_to_ns(vcpu, ticks);
+               expire = ktime_add_ns(ktime_get(), delta);
+       }
+
> rework the patch accordingly.
ok, that is fine. Thanks for catching this issue.

Regards
Bibo Mao
> 
> Thanks,
> Tao
>> Regards
>> Bibo Mao
>>> +         * Reload the remaining countdown from the migrated TVAL instead
>>> +         * of firing the timer immediately.
>>> +         */
>>> +        delta = ticks;
>>>        }
>>>          write_gcsr_timertick(delta);
>>>
>>


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-07-15  6:22 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-15  3:28 [PATCH] LoongArch: KVM: Reload one-shot TVAL on migration destination Tao Cui
2026-07-15  3:49 ` Bibo Mao
2026-07-15  5:53   ` Tao Cui
2026-07-15  6:21     ` Bibo Mao

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox