[PATCH v5 19/20] KVM: arm/arm64: Get rid of kvm_timer_flush_hwstate

Andrew Jones drjones at redhat.com
Wed Nov 29 10:17:41 PST 2017


On Wed, Nov 29, 2017 at 06:39:00PM +0100, Christoffer Dall wrote:
> On Mon, Nov 27, 2017 at 05:50:12PM +0100, Andrew Jones wrote:
> > On Fri, Oct 27, 2017 at 10:34:40AM +0200, Christoffer Dall wrote:
> > > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> > > index 132d39a..14c50d1 100644
> > > --- a/virt/kvm/arm/arm.c
> > > +++ b/virt/kvm/arm/arm.c
> > > @@ -656,7 +656,6 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
> > >  
> > >  		local_irq_disable();
> > >  
> > > -		kvm_timer_flush_hwstate(vcpu);
> > >  		kvm_vgic_flush_hwstate(vcpu);
> > >  
> > >  		/*
> > > -- 
> > > 2.7.4
> > 
> > Hi Christoffer,
> > 
> > I realize this is already merged, but I have a question about the
> > above hunk. IIUC, the patch "KVM: arm/arm64: Move timer/vgic
> > flush/sync under disabled irq" only moved kvm_vgic_flush_hwstate()
> > under disabled irq because it had to be run after
> > kvm_timer_flush_hwstate(). Now that kvm_timer_flush_hwstate() is
> > gone can/should it be moved back out?
> > 
> 
> That's a great question.
> 
> I think my reasoning was, that since we now disable the VCPU interface
> (and thereby maintenance interrupts), any logic that relies on a
> maintenance interrupt firing and causing a guest exit after we've called
> flush, would no longer work if we move this back out where interrupts
> are enabled.
> 
> Thinking about this a bit more, I don't think that would ever make
> sense, and we should be able to move it out.
> 
> I've tested these patches pretty heavily and would want such a change to
> get the same kind of exposure, so I can start testing it, and if there
> are no issues, put it in next later on in the cycle.
> 
> Does that sound reasonable?

Sounds good to me. Thanks!

drew



More information about the linux-arm-kernel mailing list