Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Maxim Levitsky <mlevitsk@redhat.com>
To:     kvm@vger.kernel.org
Cc:     "H. Peter Anvin" <hpa@zytor.com>,
        Sean Christopherson <seanjc@google.com>,
        linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        Borislav Petkov <bp@alien8.de>,
        Maxim Levitsky <mlevitsk@redhat.com>
Subject: [PATCH 0/3] Fix 'Spurious APIC interrupt (vector 0xFF) on CPU#n' issue
Date:   Tue, 18 Jul 2023 12:13:07 +0300
Message-Id: <20230718091310.119672-1-mlevitsk@redhat.com>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Recently we found an issue which causes these error messages=0D
to be sometimes logged if the guest has VFIO device attached:=0D
=0D
'Spurious APIC interrupt (vector 0xFF) on CPU#0, should never happen'=0D
=0D
It was traced to the incorrect APICv inhibition bug which started with=0D
'KVM: x86: inhibit APICv/AVIC on changes to APIC ID or APIC base'=0D
(All these issues are now fixed)=0D
=0D
However, there are valid cases for the APICv to be inhibited and it should =
not=0D
cause spurious interrupts to be injected to the guest.=0D
=0D
After some debug, the root cause was found and it is that __kvm_apic_update=
_irr=0D
doesn't set irr_pending which later triggers a int->unsigned char conversio=
n=0D
bug which leads to the wrong 0xFF injection.=0D
=0D
This also leads to an unbounded delay in injecting the interrupt and hurts=
=0D
performance.=0D
=0D
In addition to that, I also noticed that __kvm_apic_update_irr is not atomi=
c=0D
in regard to IRR, which can lead to an even harder to debug bug.=0D
=0D
Best regards,=0D
	Maxim Levitsky=0D
=0D
Maxim Levitsky (3):=0D
  KVM: x86: VMX: __kvm_apic_update_irr must update the IRR atomically=0D
  KVM: x86: VMX: set irr_pending in kvm_apic_update_irr=0D
  KVM: x86: check the kvm_cpu_get_interrupt result before using it=0D
=0D
 arch/x86/kvm/lapic.c | 23 +++++++++++++++--------=0D
 arch/x86/kvm/x86.c   | 10 +++++++---=0D
 2 files changed, 22 insertions(+), 11 deletions(-)=0D
=0D
-- =0D
2.26.3=0D
=0D