From: Sean Christopherson <seanjc@google.com>
To: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
Paul Durrant <paul@xen.org>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 2/9] KVM: x86: Drop guest/user-triggerable asserts on IRR/ISR vectors
Date: Fri, 5 Dec 2025 16:43:04 -0800 [thread overview]
Message-ID: <20251206004311.479939-3-seanjc@google.com> (raw)
In-Reply-To: <20251206004311.479939-1-seanjc@google.com>
Remove the ASSERT()s in apic_find_highest_i{r,s}r() that exist to detect
illegal vectors (0-15 are reserved and never recognized by the local APIC),
as the asserts, if they were ever to be enabled by #defining DEBUG, can be
trivially triggered from both the guest and from userspace, and ultimately
because the ASSERT()s are useless.
In large part due to lack of emulation for the Error Status Register and
its "delayed" read semantics, KVM doesn't filter out bad IRQs (IPIs or
otherwise) when IRQs are sent or received. Instead, probably by dumb
luck on KVM's part, KVM effectively ignores pending illegal vectors in
the IRR due vector 0-15 having priority '0', and thus never being higher
priority than PPR.
As for ISR, a misbehaving userspace could stuff illegal vector bits, but
again the end result is mostly benign (aside from userspace likely
breaking the VM), as processing illegal vectors "works" and doesn't cause
functional problems.
Regardless of the safety and correctness of KVM's illegal vector handling,
one thing is for certain: the ASSERT()s have done absolutely nothing to
help detect such issues since they were added 18+ years ago by commit
97222cc83163 ("KVM: Emulate local APIC in kernel").
For all intents and purposes, no functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/lapic.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 558adcb67171..785c0352fa0e 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -666,8 +666,6 @@ static inline int apic_search_irr(struct kvm_lapic *apic)
static inline int apic_find_highest_irr(struct kvm_lapic *apic)
{
- int result;
-
/*
* Note that irr_pending is just a hint. It will be always
* true with virtual interrupt delivery enabled.
@@ -675,10 +673,7 @@ static inline int apic_find_highest_irr(struct kvm_lapic *apic)
if (!apic->irr_pending)
return -1;
- result = apic_search_irr(apic);
- ASSERT(result == -1 || result >= 16);
-
- return result;
+ return apic_search_irr(apic);
}
static inline void apic_clear_irr(int vec, struct kvm_lapic *apic)
@@ -731,8 +726,6 @@ static inline void apic_set_isr(int vec, struct kvm_lapic *apic)
static inline int apic_find_highest_isr(struct kvm_lapic *apic)
{
- int result;
-
/*
* Note that isr_count is always 1, and highest_isr_cache
* is always -1, with APIC virtualization enabled.
@@ -742,10 +735,7 @@ static inline int apic_find_highest_isr(struct kvm_lapic *apic)
if (likely(apic->highest_isr_cache != -1))
return apic->highest_isr_cache;
- result = apic_find_highest_vector(apic->regs + APIC_ISR);
- ASSERT(result == -1 || result >= 16);
-
- return result;
+ return apic_find_highest_vector(apic->regs + APIC_ISR);
}
static inline void apic_clear_isr(int vec, struct kvm_lapic *apic)
--
2.52.0.223.gf5cc29aaa4-goog
next prev parent reply other threads:[~2025-12-06 0:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-06 0:43 [PATCH 0/9] KVM: x86: APIC and I/O APIC cleanups Sean Christopherson
2025-12-06 0:43 ` [PATCH 1/9] KVM: x86: Drop ASSERT()s on APIC/vCPU being non-NULL Sean Christopherson
2025-12-06 0:43 ` Sean Christopherson [this message]
2025-12-06 0:43 ` [PATCH 3/9] KVM: x86: Drop ASSERT() on I/O APIC EOIs being only for LEVEL_to WARN_ON_ONCE Sean Christopherson
2025-12-06 0:43 ` [PATCH 4/9] KVM: x86: Drop guest-triggerable ASSERT()s on I/O APIC access alignment Sean Christopherson
2025-12-06 0:43 ` [PATCH 5/9] KVM: x86: Drop MAX_NR_RESERVED_IOAPIC_PINS, use KVM_MAX_IRQ_ROUTES directly Sean Christopherson
2025-12-06 0:43 ` [PATCH 6/9] KVM: x86: Add a wrapper to handle common case of IRQ delivery without dest_map Sean Christopherson
2025-12-06 0:43 ` [PATCH 7/9] KVM: x86: Fold "struct dest_map" into "struct rtc_status" Sean Christopherson
2025-12-06 0:43 ` [PATCH 8/9] KVM: x86: Bury ioapic.h definitions behind CONFIG_KVM_IOAPIC Sean Christopherson
2025-12-06 0:43 ` [PATCH 9/9] KVM: x86: Hide KVM_IRQCHIP_KERNEL behind CONFIG_KVM_IOAPIC=y Sean Christopherson
2026-01-12 17:38 ` [PATCH 0/9] KVM: x86: APIC and I/O APIC cleanups Sean Christopherson
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=20251206004311.479939-3-seanjc@google.com \
--to=seanjc@google.com \
--cc=dwmw2@infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=vkuznets@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 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®