Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Tao Cui <cui.tao@linux.dev>
To: Bibo Mao <maobibo@loongson.cn>, zhaotianrui@loongson.cn
Cc: cui.tao@linux.dev, chenhuacai@kernel.org, kernel@xen0n.name,
	kvm@vger.kernel.org, loongarch@lists.linux.dev,
	linux-kernel@vger.kernel.org, lixianglai@loongson.cn,
	cuitao@kylinos.cn
Subject: Re: [PATCH] LoongArch: KVM: Reload one-shot TVAL on migration destination
Date: Wed, 15 Jul 2026 14:44:44 +0800	[thread overview]
Message-ID: <307287c7-9f08-48d2-b238-ef83081570bb@linux.dev> (raw)
In-Reply-To: <7ce5c447-87b7-2e8f-9c58-af1d8a211f0a@loongson.cn>



在 2026/7/15 14:21, Bibo Mao 写道:
> 
> 
> 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);
> +       }
> +

Thank you for the suggestion. I agree that kvm_restore_timer() is the
right place since all timer registers (TCFG/TVAL) are available there.

I've updated the patch to compute expire from the migrated TVAL before
the normal path, which also fixes the period timer case during migration.
Suggested-by added.

Will send v2 shortly.

Thanks,
Tao
>> 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);
>>>>
>>>
> 


      reply	other threads:[~2026-07-15  6:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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
2026-07-15  6:44       ` Tao Cui [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=307287c7-9f08-48d2-b238-ef83081570bb@linux.dev \
    --to=cui.tao@linux.dev \
    --cc=chenhuacai@kernel.org \
    --cc=cuitao@kylinos.cn \
    --cc=kernel@xen0n.name \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lixianglai@loongson.cn \
    --cc=loongarch@lists.linux.dev \
    --cc=maobibo@loongson.cn \
    --cc=zhaotianrui@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox