All of lore.kernel.org
 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 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.