Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: Amirmohammad Eftekhar <amirmohammad.eftekhar@cispa.de>,
	kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: VMX: Load the EOI-exit bitmap into vmcs01, not the active VMCS
Date: Sat, 17 Oct 2026 07:46:13 -0700	[thread overview]
Message-ID: <atOKNaeDY7UkIYJH@google.com> (raw)
In-Reply-To: <sashiko-outbox-175447@kernel.org>

On Sat, Oct 17, 2026, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] KVM: VMX: vmx_load_eoi_exitmap() comment mismatch and deferred L2 update
> --
> 
> commit b2b472dc800418ff9ed851c85722ed6e99a11a91
> Author: Amirmohammad Eftekhar <amirmohammad.eftekhar@cispa.de>
> 
> KVM: VMX: Load the EOI-exit bitmap into vmcs01, not the active VMCS
> 
> This commit adds guard(vmx_vmcs01) to vmx_load_eoi_exitmap() so that updates
> to EOI_EXIT_BITMAP0..3 target vmcs01 rather than whichever VMCS happens to be
> loaded on the CPU.
> 
> >     KVM: VMX: Load the EOI-exit bitmap into vmcs01, not the active VMCS
> >     
> >     vmx_load_eoi_exitmap() writes EOI_EXIT_BITMAP0..3 directly with
> >     vmcs_write64() and, unlike its siblings vmx_hwapic_isr_update() and
> >     vmx_sync_pir_to_irr(),
> >     does not take guard(vmx_vmcs01).  The EOI-exit bitmap belongs to L1's APIC,
> >     but with nested virtual-interrupt-delivery an L2 can be active when KVM
> >     refreshes it (e.g. via kvm_vcpu_reload_apic_access_page() /
> >     vcpu_scan_ioapic()), so the writes land in vmcs02 instead of vmcs01: L2's
> >     EOI-exit bitmap is corrupted and vmcs01's is left stale until the next L1
> >     refresh.
> >     
> >     Add guard(vmx_vmcs01), matching the sibling APICv callbacks.
> >     
> >     Signed-off-by: Amirmohammad Eftekhar <amirmohammad.eftekhar@cispa.de>
> 
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index 612ab07d4100f..ec2ea3e1d14d8 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -7139,6 +7139,13 @@ void vmx_load_eoi_exitmap(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
> >  	if (!kvm_vcpu_apicv_active(vcpu))
> >  		return;
> >  
> > +	/*
> > +	 * The EOI-exit bitmap tracks L1's APIC, so it must land in vmcs01, not
> > +	 * whichever VMCS is currently loaded; a nested VID L2 can be active
> > +	 * here.  Mirror vmx_hwapic_isr_update()/vmx_sync_pir_to_irr().
> > +	 */
> > +	guard(vmx_vmcs01)(vcpu);
> > +
> >  	vmcs_write64(EOI_EXIT_BITMAP0, eoi_exit_bitmap[0]);
> >  	vmcs_write64(EOI_EXIT_BITMAP1, eoi_exit_bitmap[1]);
> >  	vmcs_write64(EOI_EXIT_BITMAP2, eoi_exit_bitmap[2]);
> 
> [Severity: Medium]
> Can vcpu_scan_ioapic() or kvm_vcpu_reload_apic_access_page() actually trigger
> vmx_load_eoi_exitmap() while L2 is active, as described in the commit message
> and comment?

Not in normal operation, no.  Maybe if userspace does something bizarre and forces
the vCPU back into L2 after the exit, but before KVM_RUN?  Regardless, we should
rip out the deferred update, I simply missed it when removing all the others,
probably because it was buring in kvm_vcpu_arch instead of vcpu_vmx.

Not yet tested...

---
From: Sean Christopherson <seanjc@google.com>
Date: Sat, 17 Oct 2026 07:33:11 -0700
Subject: [PATCH] KVM: x86: Switch to vmcs01 to update EOIT exiting bitmap
 on-demand if L2 is active

If KVM needs to update the EOI bitmap while L2 is running, temporarily load
vmcs01 and immediately refresh the bitmap in vmcs01 instead of deferring
the update until the next nested VM-Exit.  I.e. give the EOI bitmap the
same treatment as the many other updates that were previously deferred.

Reported-by: Amirmohammad Eftekhar <amirmohammad.eftekhar@cispa.de>
Closes: https://lore.kernel.org/all/20261017093016.32348-2-amirmohammad.eftekhar@cispa.de
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/kvm_host.h |  2 +-
 arch/x86/kvm/regs.h             |  6 ------
 arch/x86/kvm/vmx/vmx.c          |  2 ++
 arch/x86/kvm/x86.c              | 13 -------------
 4 files changed, 3 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index e2eef7057bd3..9583bde5c848 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -108,7 +108,7 @@
 #define KVM_REQ_HV_RESET		KVM_ARCH_REQ(20)
 #define KVM_REQ_HV_EXIT			KVM_ARCH_REQ(21)
 #define KVM_REQ_HV_STIMER		KVM_ARCH_REQ(22)
-#define KVM_REQ_LOAD_EOI_EXITMAP	KVM_ARCH_REQ(23)
+/*#define FREE!!!  USE ME!!!		KVM_ARCH_REQ(23) */
 #define KVM_REQ_GET_NESTED_STATE_PAGES	KVM_ARCH_REQ(24)
 #define KVM_REQ_APICV_UPDATE \
 	KVM_ARCH_REQ_FLAGS(25, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
diff --git a/arch/x86/kvm/regs.h b/arch/x86/kvm/regs.h
index 97c17b120a57..04d047f46753 100644
--- a/arch/x86/kvm/regs.h
+++ b/arch/x86/kvm/regs.h
@@ -463,12 +463,6 @@ static inline void enter_guest_mode(struct kvm_vcpu *vcpu)
 static inline void leave_guest_mode(struct kvm_vcpu *vcpu)
 {
 	vcpu->arch.hflags &= ~HF_GUEST_MASK;
-
-	if (vcpu->arch.load_eoi_exitmap_pending) {
-		vcpu->arch.load_eoi_exitmap_pending = false;
-		kvm_make_request(KVM_REQ_LOAD_EOI_EXITMAP, vcpu);
-	}
-
 	vcpu->stat.guest_mode = 0;
 }
 
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index b341af4c6057..59b48d959ee0 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -7082,6 +7082,8 @@ void vmx_load_eoi_exitmap(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
 	if (!kvm_vcpu_apicv_active(vcpu))
 		return;
 
+	guard(vmx_vmcs01)(vcpu);
+
 	vmcs_write64(EOI_EXIT_BITMAP0, eoi_exit_bitmap[0]);
 	vmcs_write64(EOI_EXIT_BITMAP1, eoi_exit_bitmap[1]);
 	vmcs_write64(EOI_EXIT_BITMAP2, eoi_exit_bitmap[2]);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 32563a91fba9..0028d57e964a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8062,17 +8062,6 @@ static void vcpu_scan_ioapic(struct kvm_vcpu *vcpu)
 		kvm_ioapic_scan_entry(vcpu, vcpu->arch.ioapic_handled_vectors);
 #endif
 
-	if (is_guest_mode(vcpu))
-		vcpu->arch.load_eoi_exitmap_pending = true;
-	else
-		kvm_make_request(KVM_REQ_LOAD_EOI_EXITMAP, vcpu);
-}
-
-static void vcpu_load_eoi_exitmap(struct kvm_vcpu *vcpu)
-{
-	if (!kvm_apic_hw_enabled(vcpu->arch.apic))
-		return;
-
 #ifdef CONFIG_KVM_HYPERV
 	if (to_hv_vcpu(vcpu)) {
 		u64 eoi_exit_bitmap[4];
@@ -8240,8 +8229,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
 		}
 		if (kvm_check_request(KVM_REQ_SCAN_IOAPIC, vcpu))
 			vcpu_scan_ioapic(vcpu);
-		if (kvm_check_request(KVM_REQ_LOAD_EOI_EXITMAP, vcpu))
-			vcpu_load_eoi_exitmap(vcpu);
 		if (kvm_check_request(KVM_REQ_APIC_PAGE_RELOAD, vcpu))
 			kvm_vcpu_reload_apic_access_page(vcpu);
 #ifdef CONFIG_KVM_HYPERV

base-commit: dea4f6380f4ec96e8f3b0aaf2343764bd0d25ef4
-- 

  reply	other threads:[~2026-10-17 14:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-17  9:30 [PATCH] KVM: VMX: Load the EOI-exit bitmap into vmcs01, not the active VMCS Amirmohammad Eftekhar
2026-10-17  9:40 ` sashiko-bot
2026-10-17 14:46   ` Sean Christopherson [this message]
2026-10-17 16:33 ` Amirmohammad Eftekhar

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=atOKNaeDY7UkIYJH@google.com \
    --to=seanjc@google.com \
    --cc=amirmohammad.eftekhar@cispa.de \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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