All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
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: Wed, 25 Nov 2020 21:19:55 +0000	[thread overview]
Message-ID: <20201125211955.GA450871@google.com> (raw)
In-Reply-To: <017de9019136b5d2ec34132b96b9f0273c21d6f1.camel@infradead.org>

On Wed, Nov 25, 2020, David Woodhouse wrote:
> On Thu, 2020-11-12 at 13:03 +0000, David Woodhouse wrote:
> > I'm using nested VMX for testing, while I add split-irqchip support to
> > my VMM. I see the vCPU lock up when attempting to deliver an interrupt.
> 
> Turns out I don't need nesting or my own VMM to reproduce this; all I
> need to do is boot a guest in qemu with split-irqchip and 'noapic' on
> the guest command line. It locks up before getting to a login prompt,
> every time.
> 
> qemu-system-x86_64 -serial mon:stdio -machine q35,accel=kvm,kernel-irqchip=split -m 2G -display none -drive file=foo.qcow2,if=virtio
> 
> Commit 782d422bc ("KVM: x86: split kvm_vcpu_ready_for_interrupt_injection
> out of dm_request_for_irq_injection") made dm_request_for_irq_injection()
> return true even when kvm_cpu_has_interrupt() is true.
> 
> So we enable the vmexit on interrupt window because userspace asked for
> it, but then kvm_vcpu_ready_for_interrupt_injection() returns false,
> causing us *not* to exit all the way to userspace but just to loop in
> vcpu_run() instead.
> 
> But we *didn't* have an injectable interrupt from the kernel, so we
> just go straight back into the guest, vmexit again, loop again, ad
> infinitum.
> 
> This appears to fix it:
> 
> --- 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; 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);
}

>                 !kvm_event_needs_reinjection(vcpu) &&
>                 kvm_cpu_accept_dm_intr(vcpu);
>  }
> 



  reply	other threads:[~2020-11-25 21:20 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 [this message]
2020-11-26 11:10     ` David Woodhouse
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=20201125211955.GA450871@google.com \
    --to=seanjc@google.com \
    --cc=dwmw2@infradead.org \
    --cc=gingell@google.com \
    --cc=karahmed@amazon.de \
    --cc=kvm@vger.kernel.org \
    --cc=liran@amazon.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.