kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm <kvm@vger.kernel.org>, "Sironi, Filippo" <sironi@amazon.de>,
	"Raslan, KarimAllah" <karahmed@amazon.de>,
	Matt Gingell <gingell@google.com>,
	Steve Rutherford <srutherford@google.com>,
	liran@amazon.com
Subject: Re: [RFC PATCH] Fix split-irqchip vs interrupt injection window request.
Date: Thu, 26 Nov 2020 11:10:41 +0000	[thread overview]
Message-ID: <99a9c1dfbb21744e5081d924291d3b09ab055813.camel@infradead.org> (raw)
In-Reply-To: <20201125211955.GA450871@google.com>

[-- Attachment #1: Type: text/plain, Size: 3999 bytes --]

On Wed, 2020-11-25 at 21:19 +0000, Sean Christopherson wrote:
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -4028,7 +4028,7 @@ static int kvm_cpu_accept_dm_intr(struct kvm_vcpu *vcpu)
> >   static int kvm_vcpu_ready_for_interrupt_injection(struct kvm_vcpu *vcpu)
> >   {
> >          return kvm_arch_interrupt_allowed(vcpu) &&
> > -               !kvm_cpu_has_interrupt(vcpu) &&
> > +               !kvm_cpu_has_injectable_intr(vcpu) &&
> 
> Interrupt window exiting explicitly has priority over virtual interrupt delivery,
> so this is correct from that perspective.
> 
> But I wonder if would make sense to be more precise so that KVM behavior is
> consistent for APICv and legacy IRQ injection.  If the LAPIC is in-kernel,
> KVM_INTERRUPT can only be used for EXTINT; 

I think it should be used for injecting Xen event channel vectors too,
shouldn't it? Those have their own EOI/mask mechanism and shouldn't be
injected through the LAPIC (for example by simulating MSI to the
appropriate APIC+vector) because the guest won't EOI them there.

Although to all extents and purposes that basically means we *are*
treating them like ExtINT.

Not that it makes a difference to the outcome right now, although there
was once a patch floating around to allow KVM_INTERRUPT even when the
PIC was in-kernel, precisely for that reason.

> whether or not there's an IRQ in the
> LAPIC should be irrelevant when deciding to exit to userspace.  Note, the
> reinjection check covers vcpu->arch.interrupt.injected for the case where LAPIC
> is in userspace.
> 
>         return kvm_arch_interrupt_allowed(vcpu) &&
>                (!lapic_in_kernel(vcpu) || !kvm_cpu_has_extint(vcpu)) &&
>                !kvm_event_needs_reinjection(vcpu) &&
>                kvm_cpu_accept_dm_intr(vcpu);
> }

Makes sense. I'm putting this version through some testing and will
post it later...


diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index f002cdb13a0b..e85e2f1c661c 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1656,6 +1656,7 @@ int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long end,
 int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
 int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
 int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+int kvm_cpu_has_extint(struct kvm_vcpu *v);
 int kvm_cpu_has_injectable_intr(struct kvm_vcpu *v);
 int kvm_cpu_has_interrupt(struct kvm_vcpu *vcpu);
 int kvm_arch_interrupt_allowed(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index 99d118ffc67d..9c4ef1682b81 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -40,7 +40,7 @@ static int pending_userspace_extint(struct kvm_vcpu *v)
  * check if there is pending interrupt from
  * non-APIC source without intack.
  */
-static int kvm_cpu_has_extint(struct kvm_vcpu *v)
+int kvm_cpu_has_extint(struct kvm_vcpu *v)
 {
 	u8 accept = kvm_apic_accept_pic_intr(v);
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a3fdc16cfd6f..b50ae8ba66e9 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4080,12 +4080,14 @@ static int kvm_cpu_accept_dm_intr(struct kvm_vcpu *vcpu)
  * if userspace requested an interrupt window, check that the
  * interrupt window is open.
  *
- * No need to exit to userspace if we already have an interrupt queued.
+ * If there is already an event which needs reinjection or a
+ * pending ExtINT, allow that to be processed by the kernel
+ * before letting userspace have the opportunity.
  */
 static int kvm_vcpu_ready_for_interrupt_injection(struct kvm_vcpu *vcpu)
 {
 	return kvm_arch_interrupt_allowed(vcpu) &&
-		!kvm_cpu_has_interrupt(vcpu) &&
+		!(lapic_in_kernel(vcpu) && kvm_cpu_has_extint(vcpu)) &&
 		!kvm_event_needs_reinjection(vcpu) &&
 		kvm_cpu_accept_dm_intr(vcpu);
 }

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

  reply	other threads:[~2020-11-26 11:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-12 13:03 [RFC] Further hack request_interrupt_window handling to work around kvm_cpu_has_interrupt() nesting breakage David Woodhouse
2020-11-25 15:10 ` [RFC PATCH] Fix split-irqchip vs interrupt injection window request David Woodhouse
2020-11-25 21:19   ` Sean Christopherson
2020-11-26 11:10     ` David Woodhouse [this message]
2020-11-26 12:05       ` [PATCH] kvm/x86: Fix simultaneous ExtINT and lapic interrupt handling with APICv David Woodhouse
2020-11-26 18:00         ` Paolo Bonzini
2020-11-26 19:07           ` David Woodhouse
2020-11-26 17:29       ` [RFC PATCH] Fix split-irqchip vs interrupt injection window request David Woodhouse
2020-11-26 17:59         ` Paolo Bonzini
2020-11-26 21:48           ` David Woodhouse
2020-11-27  4:37             ` Paolo Bonzini

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=99a9c1dfbb21744e5081d924291d3b09ab055813.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=gingell@google.com \
    --cc=karahmed@amazon.de \
    --cc=kvm@vger.kernel.org \
    --cc=liran@amazon.com \
    --cc=seanjc@google.com \
    --cc=sironi@amazon.de \
    --cc=srutherford@google.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;
as well as URLs for NNTP newsgroup(s).