All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: check PIR even for vCPUs with disabled APICv
Date: Wed, 17 Nov 2021 21:10:17 +0000	[thread overview]
Message-ID: <YZVvuRdLcxZclw+1@google.com> (raw)
In-Reply-To: <20211117080744.995111-1-pbonzini@redhat.com>

On Wed, Nov 17, 2021, Paolo Bonzini wrote:
> After fixing the handling of POSTED_INTR_WAKEUP_VECTOR for vCPUs with
> disabled APICv, take care of POSTED_INTR_VECTOR.  The IRTE for an assigned
> device can trigger a POSTED_INTR_VECTOR even if APICv is disabled on the
> vCPU that receives it.  In that case, the interrupt will just cause a
> vmexit and leave the ON bit set together with the PIR bit corresponding
> to the interrupt.
> 
> Right now, the interrupt would not be delivered until APICv is re-enabled.
> However, fixing this is just a matter of always doing the PIR->IRR
> synchronization, even if the vCPU does not have APICv enabled.
> 
> This is not a problem for performance, or if anything it is an
> improvement.  static_call_cond will elide the function call if APICv is
> not present or disabled, or if (as is the case for AMD hardware) it does
> not require a sync_pir_to_irr callback.

The AMD part is not accurate, SVM's sync_pir_to_irr() is wired up to point at
kvm_lapic_find_highest_irr().  That can and probably should be fixed in a separate
patch, 

And I believe apic_has_interrupt_for_ppr() needs to be updated as well.

We can handled both at once by nullifying SVM's hook and explicitly checking for
a non-NULL implementation in apic_has_interrupt_for_ppr(), which is the only path
that cares about the result of sync_pir_to_irr(), i.e. needs to do the work in
the SVM case.

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 4388d22df500..1456745cf5c6 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -707,7 +707,8 @@ static void pv_eoi_clr_pending(struct kvm_vcpu *vcpu)
 static int apic_has_interrupt_for_ppr(struct kvm_lapic *apic, u32 ppr)
 {
        int highest_irr;
-       if (apic->vcpu->arch.apicv_active)
+
+       if (kvm_x86_ops.sync_pir_to_irr)
                highest_irr = static_call(kvm_x86_sync_pir_to_irr)(apic->vcpu);
        else
                highest_irr = apic_find_highest_irr(apic);
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index ccbf96876ec6..470552e68b7e 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -4649,7 +4649,7 @@ static struct kvm_x86_ops svm_x86_ops __initdata = {
        .load_eoi_exitmap = svm_load_eoi_exitmap,
        .hwapic_irr_update = svm_hwapic_irr_update,
        .hwapic_isr_update = svm_hwapic_isr_update,
-       .sync_pir_to_irr = kvm_lapic_find_highest_irr,
+       .sync_pir_to_irr = NULL,
        .apicv_post_state_restore = avic_post_state_restore,

        .set_tss_addr = svm_set_tss_addr,

      reply	other threads:[~2021-11-17 21:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-17  8:07 [PATCH] KVM: x86: check PIR even for vCPUs with disabled APICv Paolo Bonzini
2021-11-17 21:10 ` 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=YZVvuRdLcxZclw+1@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=stable@vger.kernel.org \
    /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.