public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoffer Dall <cdall@linaro.org>
To: Andrew Jones <drjones@redhat.com>
Cc: marc.zyngier@arm.com, pbonzini@redhat.com,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: Re: [PATCH v4 09/11] KVM: arm/arm64: use vcpu requests for irq injection
Date: Thu, 1 Jun 2017 15:27:16 +0200	[thread overview]
Message-ID: <20170601132716.GL20919@cbox> (raw)
In-Reply-To: <20170601105921.ggkuxft6nb32yio5@kamzik.brq.redhat.com>

On Thu, Jun 01, 2017 at 12:59:21PM +0200, Andrew Jones wrote:
> On Thu, Jun 01, 2017 at 12:35:33PM +0200, Christoffer Dall wrote:
> > On Tue, May 16, 2017 at 04:20:33AM +0200, Andrew Jones wrote:
> > > Don't use request-less VCPU kicks when injecting IRQs, as a VCPU
> > > kick meant to trigger the interrupt injection could be sent while
> > > the VCPU is outside guest mode, which means no IPI is sent, and
> > > after it has called kvm_vgic_flush_hwstate(), meaning it won't see
> > > the updated GIC state until its next exit some time later for some
> > > other reason.  The receiving VCPU only needs to check this request
> > > in VCPU RUN to handle it.  By checking it, if it's pending, a
> > > memory barrier will be issued that ensures all state is visible.
> > > We still create a vcpu_req_irq_pending() function (which is a nop),
> > > though, in order to allow us to use the standard request checking
> > > pattern.
> > > 
> > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > ---
> > >  arch/arm/include/asm/kvm_host.h   |  1 +
> > >  arch/arm64/include/asm/kvm_host.h |  1 +
> > >  virt/kvm/arm/arm.c                | 12 ++++++++++++
> > >  virt/kvm/arm/vgic/vgic.c          |  9 +++++++--
> > >  4 files changed, 21 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> > > index fdd644c01c89..00ad56ee6455 100644
> > > --- a/arch/arm/include/asm/kvm_host.h
> > > +++ b/arch/arm/include/asm/kvm_host.h
> > > @@ -46,6 +46,7 @@
> > >  
> > >  #define KVM_REQ_SLEEP \
> > >  	KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> > > +#define KVM_REQ_IRQ_PENDING	KVM_ARCH_REQ(1)
> > >  
> > >  u32 *kvm_vcpu_reg(struct kvm_vcpu *vcpu, u8 reg_num, u32 mode);
> > >  int __attribute_const__ kvm_target_cpu(void);
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index 9bd0d1040de9..0c4fd1f46e10 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -43,6 +43,7 @@
> > >  
> > >  #define KVM_REQ_SLEEP \
> > >  	KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> > > +#define KVM_REQ_IRQ_PENDING	KVM_ARCH_REQ(1)
> > >  
> > >  int __attribute_const__ kvm_target_cpu(void);
> > >  int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
> > > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> > > index ddc833987dfb..73a75ca91e41 100644
> > > --- a/virt/kvm/arm/arm.c
> > > +++ b/virt/kvm/arm/arm.c
> > > @@ -570,6 +570,15 @@ static void vcpu_req_sleep(struct kvm_vcpu *vcpu)
> > >  	}
> > >  }
> > >  
> > > +static void vcpu_req_irq_pending(struct kvm_vcpu *vcpu)
> > > +{
> > > +	/*
> > > +	 * Nothing to do here. kvm_check_request() already issued a memory
> > > +	 * barrier that pairs with kvm_make_request(), so all hardware state
> > > +	 * we need to flush should now be visible.
> > > +	 */
> > 
> > I don't understand this comment :(
> 
> We need a kvm_check_request() to pair with a requesting VCPU's setting
> of virtual irq state and call of kvm_make_request(). The requester's
> kvm_make_request() ensures the target VCPU executes VCPU RUN, and the
> barriers wrapped in kvm_check/make_request() ensure that when VCPU RUN
> calls kvm_vgic_flush_hwstate() that the virtual irq state set by the
> requester is visible to the target VCPU.
> 
> But you knew all that already :-) So, maybe I just need to replace
> 'all hardware state we need to flush should now be visible.' with
> 'the virtual irq state is now visible.'?
> 

Yes, the hardware state is definitely vague here, but I also feel like
you're trying to repeat parts of the documentation here, and it's better
to just refer to the complete documentation for the how the barreirs
etc. work, and just explain why you don't need to do anything, yet still
have a vcpu request.

Which is why I suggested the alternative comment below instead ;)

> > 
> > And I don't much like this empty function either.
> > 
> > 
> > > +}
> > > +
> > >  static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu)
> > >  {
> > >  	return vcpu->arch.target >= 0;
> > > @@ -580,6 +589,8 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu)
> > >  	if (kvm_request_pending(vcpu)) {
> > >  		if (kvm_check_request(KVM_REQ_SLEEP, vcpu))
> > >  			vcpu_req_sleep(vcpu);
> > > +		if (kvm_check_request(KVM_REQ_IRQ_PENDING, vcpu))
> > > +			vcpu_req_irq_pending(vcpu);
> > 
> > 
> > Can we just do:
> > 		/* 
> > 		 * Clear IRQ_PENDING requests that were made to
> > 		 * guarantee that a VCPU sees new virtual interrupts.
> > 		 */
> > 		kvm_check_request(KVM_REQ_IRQ_PENDING, vcpu);
> > 
> > ?
> 
> I won't insist, but I prefer the empty function to breaking the pattern
> of this if-sequence, and also to the calling of a function named "check"
> without considering its return value.

I like scratching our OCD as much as the next reviewer, but I think my
version more clearly expresses the purpose, which is more important than
having multiple identically-looking statements.

Thanks,
-Christoffer

  reply	other threads:[~2017-06-01 13:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-16  2:20 [PATCH v4 00/11] KVM: arm/arm64: race fixes and vcpu requests Andrew Jones
2017-05-16  2:20 ` [PATCH v4 01/11] KVM: improve arch vcpu request defining Andrew Jones
2017-06-01 10:34   ` Christoffer Dall
2017-05-16  2:20 ` [PATCH v4 02/11] KVM: add kvm_request_pending Andrew Jones
2017-06-01 10:35   ` Christoffer Dall
2017-05-16  2:20 ` [PATCH v4 03/11] KVM: Add documentation for VCPU requests Andrew Jones
2017-05-26  7:31   ` Christoffer Dall
2017-05-26  9:43     ` Andrew Jones
2017-05-16  2:20 ` [PATCH v4 04/11] KVM: arm/arm64: properly use vcpu requests Andrew Jones
2017-05-16  2:20 ` [PATCH v4 05/11] KVM: arm/arm64: replace pause checks with vcpu request checks Andrew Jones
2017-06-01 10:35   ` Christoffer Dall
2017-05-16  2:20 ` [PATCH v4 06/11] KVM: arm/arm64: use vcpu requests for power_off Andrew Jones
2017-06-01 10:35   ` Christoffer Dall
2017-06-01 10:35   ` Christoffer Dall
2017-05-16  2:20 ` [PATCH v4 07/11] KVM: arm/arm64: optimize VCPU RUN Andrew Jones
2017-06-01 10:35   ` Christoffer Dall
2017-05-16  2:20 ` [PATCH v4 08/11] KVM: arm/arm64: change exit request to sleep request Andrew Jones
2017-06-01 10:35   ` Christoffer Dall
2017-05-16  2:20 ` [PATCH v4 09/11] KVM: arm/arm64: use vcpu requests for irq injection Andrew Jones
2017-06-01 10:35   ` Christoffer Dall
2017-06-01 10:59     ` Andrew Jones
2017-06-01 13:27       ` Christoffer Dall [this message]
2017-06-01 13:38         ` Andrew Jones
2017-06-01 13:53           ` Christoffer Dall
2017-05-16  2:20 ` [PATCH v4 10/11] KVM: arm/arm64: PMU: remove request-less vcpu kick Andrew Jones
2017-05-16  2:20 ` [PATCH v4 11/11] KVM: arm/arm64: timer: " Andrew Jones
2017-06-01 10:34   ` Christoffer Dall
2017-06-01 11:09     ` Andrew Jones
2017-06-01 12:37       ` Paolo Bonzini
2017-06-01 13:23         ` Christoffer Dall

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=20170601132716.GL20919@cbox \
    --to=cdall@linaro.org \
    --cc=drjones@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=marc.zyngier@arm.com \
    --cc=pbonzini@redhat.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