From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Clamp the EOI vector if its OOB instead of bugging the kernel
Date: Wed, 24 Jun 2026 06:18:56 -0700 [thread overview]
Message-ID: <ajvZQFzfYKcfgiJo@google.com> (raw)
In-Reply-To: <3948934a-eb84-418f-b29e-c1176b47370d@redhat.com>
On Wed, Jun 24, 2026, Paolo Bonzini wrote:
> On 6/18/26 20:55, Sean Christopherson wrote:
> > If KVM handles an I/O APIC EOI exit request with a bad vector, clamp the
> > vector to 255 and hope for the best instead of bugging the host. In all
> > likelihood, a missed EOI is survivable for the guest, and it's most
> > definitely not remotely fatal to the host, i.e. potentially panicking the
> > host is completely unjustified. Arbitrarily use 255 for the dummy vector,
> > the goal is purely to ensure the vector is covered by the bitmap.
> >
> > Opportunistically ensure the EOI vector isn't negative, as it's a signed
> > integer, i.e. the "greater than 255" check won't guard against setting the
> > vector to a negative value (KVM uses -1 to say "no IRQ" in many flows).
> >
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> > arch/x86/kvm/x86.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index d9d51803b7b2..fda09e03b960 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -11212,7 +11212,10 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> > if (kvm_check_request(KVM_REQ_NMI, vcpu))
> > process_nmi(vcpu);
> > if (kvm_check_request(KVM_REQ_IOAPIC_EOI_EXIT, vcpu)) {
> > - BUG_ON(vcpu->arch.pending_ioapic_eoi > 255);
> > + if (WARN_ON_ONCE(vcpu->arch.pending_ioapic_eoi < 0 ||
> > + vcpu->arch.pending_ioapic_eoi > 255))
> > + vcpu->arch.pending_ioapic_eoi = 255;
> > +
>
> Yay, it's my turn to say "why?!?" I'm not going to go full Linus on
> it :) but I've been waiting for the moment for years!
LOL. Well, well, well, if it isn't the consequences of my own actions.
> If this happens we have a much bigger problem: the vector is set in
> kvm_ioapic_send_eoi() and ultimately comes from apic_find_highest_isr().
> It is simply not going to happen.
>
> Unlike pending_external_vector or highest_stale_pending_ioapic_eoi, this
> cannot even be -1...255 so make it u8 and call it a day?
Ya, that's waaay better, especially since pending_ioapic_eoi defaults to '0'
anyways.
prev parent reply other threads:[~2026-06-24 13:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-18 18:55 [PATCH] KVM: x86: Clamp the EOI vector if its OOB instead of bugging the kernel Sean Christopherson
2026-06-19 4:51 ` Huang, Kai
2026-06-22 23:55 ` Sean Christopherson
2026-06-23 10:29 ` Huang, Kai
2026-06-24 9:50 ` Paolo Bonzini
2026-06-24 13:18 ` Sean Christopherson [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=ajvZQFzfYKcfgiJo@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.