From: Thomas Gleixner <tglx@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>
Cc: Jim Mattson <jmattson@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Binbin Wu <binbin.wu@linux.intel.com>,
Vishal L Verma <vishal.l.verma@intel.com>,
kvm <kvm@vger.kernel.org>,
Rick P Edgecombe <rick.p.edgecombe@intel.com>,
Binbin Wu <binbin.wu@intel.com>,
the arch/x86 maintainers <x86@kernel.org>,
Paolo Bonzini <bonzini@redhat.com>
Subject: Re: CPU Lockups in KVM with deferred hrtimer rearming
Date: Wed, 22 Apr 2026 00:48:18 +0200 [thread overview]
Message-ID: <87tst49bgt.ffs@tglx> (raw)
In-Reply-To: <CABgObfaNaDYCo_rkkwAnFzKYYe9G9wnz1+yiv0H73CbtE8AXpw@mail.gmail.com>
On Tue, Apr 21 2026 at 21:39, Paolo Bonzini wrote:
> Il mar 21 apr 2026, 19:55 Sean Christopherson <seanjc@google.com> ha scritto:
>> Even if performance is "fine", changing decades of fundamental KVM behavior is
>> terrifying.
>
> ... it's not decades, ack on VM exit is actually relatively recent (10
> years out 20 :)). The reason why it was introduced is another killer
> for the idea, though. Posted interrupts require it, for some reason
> only known to Intel.
That's yet another attempt to provide an halfways decent argument, but
as anything else related to KVM/VIRT it is neither documented nor proven
to be true.
Your claim is just another prove of the KVM handwaving approach as the
change log which introduced this (commit a547c6db4d2f) does not mention
it at all. In fact posted interrupt support came _three_ years after
that and there is exactly _zero_ information about this dependency if I
read the relevant change logs correctly.
Especially commit f2485b3e0c6c ("KVM: x86: use guest_exit_irqoff") which
fundamentally changed the behavior from regs::flags::IF = 1 to
regs::flags::IF = 0 does not mention this at all:
KVM: x86: use guest_exit_irqoff
This gains a few clock cycles per vmexit. On Intel there is no need
anymore to enable the interrupts in vmx_handle_external_intr, since
we are using the "acknowledge interrupt on exit" feature. AMD
needs to do that, and must be careful to avoid the interrupt shadow.
Written and committed by a Paolo Bonzini dude. You might know him
perhaps.
Where exactly is the reference to posted interrupts and how did you or
someone else establish that this hack is a requirement for posted
interrupts in the first place?
Nice try. Try again.
Thanks,
tglx
next prev parent reply other threads:[~2026-04-21 22:48 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 20:50 CPU Lockups in KVM with deferred hrtimer rearming Verma, Vishal L
2026-04-20 15:00 ` Thomas Gleixner
2026-04-20 15:22 ` Thomas Gleixner
2026-04-20 20:57 ` Verma, Vishal L
2026-04-20 22:19 ` Thomas Gleixner
2026-04-20 22:24 ` Verma, Vishal L
2026-04-21 6:29 ` Thomas Gleixner
2026-04-21 4:51 ` Binbin Wu
2026-04-21 7:39 ` Thomas Gleixner
2026-04-21 11:18 ` Peter Zijlstra
2026-04-21 11:32 ` Peter Zijlstra
2026-04-21 11:34 ` Peter Zijlstra
2026-04-21 11:49 ` Peter Zijlstra
2026-04-21 12:05 ` Peter Zijlstra
2026-04-21 13:19 ` Peter Zijlstra
2026-04-21 13:29 ` Peter Zijlstra
2026-04-21 16:36 ` Thomas Gleixner
2026-04-21 18:11 ` Verma, Vishal L
2026-04-21 17:11 ` Thomas Gleixner
2026-04-21 17:20 ` Jim Mattson
2026-04-21 18:29 ` Thomas Gleixner
2026-04-21 18:55 ` Sean Christopherson
2026-04-21 20:06 ` Peter Zijlstra
2026-04-21 20:46 ` Peter Zijlstra
2026-04-21 20:57 ` Sean Christopherson
2026-04-21 21:02 ` Peter Zijlstra
2026-04-21 21:42 ` Sean Christopherson
2026-04-22 6:55 ` Peter Zijlstra
2026-04-21 20:39 ` Paolo Bonzini
2026-04-21 21:02 ` Sean Christopherson
2026-04-21 22:48 ` Thomas Gleixner [this message]
2026-04-21 23:15 ` Paolo Bonzini
2026-04-21 23:34 ` Jim Mattson
2026-04-21 23:37 ` Paolo Bonzini
2026-04-22 2:10 ` Thomas Gleixner
2026-04-21 21:49 ` Thomas Gleixner
2026-04-21 22:07 ` Sean Christopherson
2026-04-21 22:24 ` Paolo Bonzini
2026-04-21 19:18 ` Verma, Vishal L
2026-04-21 16:30 ` Thomas Gleixner
2026-04-21 16:11 ` Verma, Vishal L
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=87tst49bgt.ffs@tglx \
--to=tglx@kernel.org \
--cc=binbin.wu@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=bonzini@redhat.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=vishal.l.verma@intel.com \
--cc=x86@kernel.org \
/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