From: Chao Gao <chao.gao@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, Yong He <zhuangel570@gmail.com>,
"Maxim Levitsky" <mlevitsk@redhat.com>
Subject: Re: [PATCH] KVM: x86: Update irr_pending when setting APIC state with APICv disabled
Date: Thu, 7 Nov 2024 12:59:30 +0800 [thread overview]
Message-ID: <ZyxJMoYMfQKug02q@intel.com> (raw)
In-Reply-To: <Zyt1Cw8LT50rMKvf@google.com>
On Wed, Nov 06, 2024 at 05:54:19AM -0800, Sean Christopherson wrote:
>On Wed, Nov 06, 2024, Chao Gao wrote:
>> >Furthermore, in addition to introducing this issue, commit 755c2bf87860 also
>> >papered over the underlying bug: KVM doesn't ensure CPUs and devices see APICv
>> >as disabled prior to searching the IRR. Waiting until KVM emulates EOI to update
>> >irr_pending works because KVM won't emulate EOI until after refresh_apicv_exec_ctrl(),
>> >and because there are plenty of memory barries in between, but leaving irr_pending
>> >set is basically hacking around bad ordering, which I _think_ can be fixed by:
>> >
>> >diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> >index 83fe0a78146f..85d330b56c7e 100644
>> >--- a/arch/x86/kvm/x86.c
>> >+++ b/arch/x86/kvm/x86.c
>> >@@ -10548,8 +10548,8 @@ void __kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu)
>> > goto out;
>> >
>> > apic->apicv_active = activate;
>> >- kvm_apic_update_apicv(vcpu);
>> > kvm_x86_call(refresh_apicv_exec_ctrl)(vcpu);
>> >+ kvm_apic_update_apicv(vcpu);
>>
>> I may miss something important. how does this change ensure CPUs and devices see
>> APICv as disabled (thus won't manipulate the vCPU's IRR)? Other CPUs when
>> performing IPI virtualization just looks up the PID_table while IOMMU looks up
>> the IRTE table. ->refresh_apicv_exec_ctrl() doesn't change any of them.
>
>For Intel, which is a bug (one of many in this area). AMD does update both. The
>failure Maxim was addressing was on AMD (AVIC), which has many more scenarios where
>it needs to be inhibited/disabled.
Yes indeed. Actually the commit below fixes the bug for Intel already. Just the
approach isn't to let other CPUs and devices see APICv disabled. Instead, pick
up all pending IRQs (in PIR) before VM-entry and cancel VM-entry if needed.
1 commit 7e1901f6c86c896acff6609e0176f93f756d8b2a
2 Author: Paolo Bonzini <pbonzini@redhat.com>
3 Date: Mon Nov 22 19:43:09 2021 -0500
4
5 KVM: VMX: prepare sync_pir_to_irr for running with APICv disabled
6
7 If APICv is disabled for this vCPU, assigned devices may still attempt to
8 post interrupts. In that case, we need to cancel the vmentry and deliver
9 the interrupt with KVM_REQ_EVENT. Extend the existing code that handles
10 injection of L1 interrupts into L2 to cover this case as well.
11
12 vmx_hwapic_irr_update is only called when APICv is active so it would be
13 confusing to add a check for vcpu->arch.apicv_active in there. Instead,
14 just use vmx_set_rvi directly in vmx_sync_pir_to_irr.
next prev parent reply other threads:[~2024-11-07 4:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-01 19:35 [PATCH] KVM: x86: Update irr_pending when setting APIC state with APICv disabled Sean Christopherson
2024-11-05 4:54 ` Sean Christopherson
2024-11-06 10:55 ` Chao Gao
2024-11-06 13:54 ` Sean Christopherson
2024-11-07 4:59 ` Chao Gao [this message]
2024-11-07 15:25 ` 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=ZyxJMoYMfQKug02q@intel.com \
--to=chao.gao@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=zhuangel570@gmail.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