From: fuqiang wang <fuqiang.wng@gmail.com>
To: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
Maxim Levitsky <mlevitsk@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: fuqiang wang <fuqiang.wng@gmail.com>, yu chen <33988979@163.com>,
dongxu zhang <xu910121@sina.com>
Subject: [PATCH v3 0/2] KVM: x86: fix some kvm period timer BUG
Date: Wed, 22 Oct 2025 23:00:53 +0800 [thread overview]
Message-ID: <20251022150055.2531-1-fuqiang.wng@gmail.com> (raw)
The following two patches fix some bugs in the x86 KVM periodic timer.
=======
patch 1
=======
The first patch fixes a problem where, if the next period has already
expired, e.g. due to the period being smaller than the delay in processing
the timer, the hv timer will switch to the software timer and never switch
back.
The reproduction steps and patch verification results at link [1].
=======
patch 2
=======
The second patch fixes an issue where, if the first patch has not been
applied, resuming a virtual machine after it has been suspended for a long
time may trigger a hard lockup. Link [2] also talks about this issue.
Link [2] also talks about this issue, but I don't think it can actually
reproduce the problem. Because of commit [3], as long as the KVM timer is
running, target_expiration will keep catching up to now (unless every
single delay from timer virtualization is longer than the period, which is
a pretty extreme case). Also, patch 2 is based on the changes in link [2],
but with some differences: In link [2], target_expiration is updated to
"now - period", and I'm not sure why it doesn't just catch up to now-maybe
I'm missing something? In patch 2, I tentatively set target_expiration to
catch up to now.
The reproduction steps and patch verification results at link [4].
=============================================================
other questions -- Should the two patches be merged into one?
=============================================================
If we end up making target_expiration catch up to now, patch 1 and patch 2
could probably be combined, since we wouldn't need the delta > 0 check
anymore. But keeping them separate helps clearly show the two different
problems we're fixing.
However, the hardlockup issue only occurs when patch 1 is not merged, which
leads to the commit message for the second patch repeatedly mentioning
"...previous patch is merged". I'm not sure if this is appropriate, so I
would like to hear your suggestions.
[1]: https://github.com/cai-fuqiang/kernel_test/tree/master/period_timer_test
[2]: https://lore.kernel.org/kvm/YgahsSubOgFtyorl@fuller.cnet/
[3]: d8f2f498d9ed ("x86/kvm: fix LAPIC timer drift when guest uses periodic mode")
[4]: https://github.com/cai-fuqiang/md/tree/master/case/intel_kvm_period_timer
Changes in v3:
- Fix: advanced SW timer (hrtimer) expiration does not catch up to current
time.
- optimize the commit message of patch 2
- link to v2: https://lore.kernel.org/all/20251021154052.17132-1-fuqiang.wng@gmail.com/
Changes in v2:
- Added a bugfix for hardlockup in v2
- link to v1: https://lore.kernel.org/all/20251013125117.87739-1-fuqiang.wng@gmail.com/
fuqiang wang (2):
avoid hv timer fallback to sw timer if delay exceeds period
fix hardlockup when waking VM after long suspend
arch/x86/kvm/lapic.c | 32 ++++++++++++++++++++++++--------
1 file changed, 24 insertions(+), 8 deletions(-)
--
2.47.0
next reply other threads:[~2025-10-22 15:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 15:00 fuqiang wang [this message]
2025-10-22 15:00 ` [PATCH v3 1/2] avoid hv timer fallback to sw timer if delay exceeds period fuqiang wang
2025-10-22 15:00 ` [PATCH v3 2/2] fix hardlockup when waking VM after long suspend fuqiang wang
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=20251022150055.2531-1-fuqiang.wng@gmail.com \
--to=fuqiang.wng@gmail.com \
--cc=33988979@163.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xu910121@sina.com \
/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
all inboxes | Powered by JetHome®