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 v2] KVM: x86: check PIR even for vCPUs with disabled APICv
Date: Thu, 18 Nov 2021 16:18:26 +0000 [thread overview]
Message-ID: <YZZ80rok+NbpI6lJ@google.com> (raw)
In-Reply-To: <20211118072531.1534938-1-pbonzini@redhat.com>
On Thu, Nov 18, 2021, Paolo Bonzini wrote:
> 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 has temporarily disabled APICv.
>
> This is not a problem for performance, or if anything it is an
> improvement. First, in the common case where vcpu->arch.apicv_active is
> true, one fewer check has to be performed. Second, static_call_cond will
> elide the function call if APICv is not present or disabled. Finally,
> in the case for AMD hardware we can remove the sync_pir_to_irr callback:
> it is only needed for apic_has_interrupt_for_ppr, and that function
> already has a fallback for !APICv.
>
> Cc: stable@vger.kernel.org
> Co-developed-by: Sean Christopherson <seanjc@google.com>
For my bits:
Signed-off-by: Sean Christopherson <seanjc@google.com>
prev parent reply other threads:[~2021-11-18 16:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-18 7:25 [PATCH v2] KVM: x86: check PIR even for vCPUs with disabled APICv Paolo Bonzini
2021-11-18 9:56 ` Maxim Levitsky
2021-11-18 11:11 ` Paolo Bonzini
2021-11-18 11:17 ` Maxim Levitsky
2021-11-18 16:17 ` Sean Christopherson
2021-11-18 17:56 ` Paolo Bonzini
2021-11-18 16:18 ` 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=YZZ80rok+NbpI6lJ@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.