All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Steve Rutherford <srutherford@google.com>,
	KVM list <kvm@vger.kernel.org>
Subject: Re: [PATCH v5 4/4] KVM: x86: Add support for local interrupt requests from userspace
Date: Wed, 29 Jul 2015 00:05:37 +0200	[thread overview]
Message-ID: <55B7FCB1.1020508@redhat.com> (raw)
In-Reply-To: <20150728190635.GA7460@google.com>



On 28/07/2015 21:06, Steve Rutherford wrote:
>>> > > +		if (!kvm_run->ready_for_interrupt_injection &&
>>> > > +		    ready_for_interrupt_injection)
>>> > > +			kvm_make_request(KVM_REQ_PIC_UNMASK_EXIT, vcpu);
>>> > > +
>>> > > +		kvm_run->ready_for_interrupt_injection =
>>> > > +				ready_for_interrupt_injection;
>>> > > +	} else {
>>> > >  		kvm_run->ready_for_interrupt_injection =
>>> > >  			kvm_arch_interrupt_allowed(vcpu) &&
>>> > >  			!kvm_cpu_has_interrupt(vcpu) &&
>>> > >  			!kvm_event_needs_reinjection(vcpu);
>>> > > +	}
>>> > >  }
>>> > >  
>>> > >  static void update_cr8_intercept(struct kvm_vcpu *vcpu)
>> > 
>> > Why is this necessary?  Could it just set
>> > kvm_run->ready_for_interrupt_injection as in the pic_in_kernel case?
> The goal is to couple the interrupt ack cycle as closely as possible
> with the injection of the local interrupt (which occur more or less
> atomically on real hardware). The idea is to only ever attempt to
> inject local interrupts when the CPU/APIC is ready to immediately
> accept. 

Ok, I understand it now.  However, you're still not causing an exit 
when LVT0 changes, are you?  post_kvm_run_save is not run until the
next exit to userspace, which could be a long time later.

So, I think that you do not need KVM_REQ_PIC_UNMASK_EXIT.  Instead,
you can modify dm_request_for_irq_injection to handle the split-irqchip
case, like this:

	if (!vcpu->run->request_interrupt_window || pic_in_kernel(vcpu->kvm))
		return false;

	if (kvm_cpu_has_interrupt(vcpu))
		return false;

        return (irqchip_split(vcpu->kvm)
                ? kvm_apic_accept_pic_intr(vcpu)
		: kvm_arch_interrupt_allowed(vcpu));

This will cause KVM_RUN to return -EINTR, which QEMU happens to handle
the same way as KVM_EXIT_IRQ_WINDOW_OPEN.  If you prefer the explicit
reason, this small change will provide it:

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 5ef2560075bf..3269169233fb 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6720,8 +6720,8 @@ static int vcpu_run(struct kvm_vcpu *vcpu)
 			kvm_inject_pending_timer_irqs(vcpu);
 
 		if (dm_request_for_irq_injection(vcpu)) {
-			r = -EINTR;
-			vcpu->run->exit_reason = KVM_EXIT_INTR;
+			r = 0;
+			vcpu->run->exit_reason = KVM_EXIT_IRQ_WINDOW_OPEN;
 			++vcpu->stat.request_irq_exits;
 			break;
 		}

Feel free to post v6 of this patch only.  Everything else is mostly
okay; there are some leftovers here and there (lapic_in_kernel,
GET_VECTOR_FROM_USERSPACE) but I can fix that.

How is the integration with QEMU going?  With this latest iteration
it should be relatively easy.

Paolo

  reply	other threads:[~2015-07-28 22:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-27 23:17 [PATCH v5 1/4] KVM: x86: Split the APIC from the rest of IRQCHIP Steve Rutherford
2015-07-27 23:17 ` [PATCH v5 2/4] KVM: x86: Add KVM exit for IOAPIC EOIs Steve Rutherford
2015-07-27 23:17 ` [PATCH v5 3/4] KVM: x86: Add EOI exit bitmap inference Steve Rutherford
2015-07-29 12:38   ` Paolo Bonzini
2015-07-29 20:27     ` Steve Rutherford
2015-07-30  6:23       ` Jan Kiszka
2015-07-30  6:27         ` Steve Rutherford
2015-07-27 23:17 ` [PATCH v5 4/4] KVM: x86: Add support for local interrupt requests from userspace Steve Rutherford
2015-07-28 15:58   ` Paolo Bonzini
2015-07-28 19:06     ` Steve Rutherford
2015-07-28 22:05       ` Paolo Bonzini [this message]
2015-07-29  0:50         ` Steve Rutherford
2015-07-29 10:21       ` Paolo Bonzini
2015-07-29 10:15   ` Paolo Bonzini
2015-07-29 12:56 ` [PATCH v5 1/4] KVM: x86: Split the APIC from the rest of IRQCHIP Paolo Bonzini
2015-07-30  3:04   ` Steve Rutherford

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=55B7FCB1.1020508@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=kvm@vger.kernel.org \
    --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.