On Wed, Mar 08, 2017 at 06:33:12AM -0800, Christoffer Dall wrote: > > static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu) > > @@ -621,7 +617,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run) > > > > update_vttbr(vcpu->kvm); > > > > - if (vcpu->arch.power_off || vcpu->arch.pause) > > + if (vcpu->arch.power_off || __kvm_request_test(KVM_REQ_VCPU_PAUSE, vcpu)) > > vcpu_sleep(vcpu); > > > > /* > > @@ -644,8 +640,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run) > > run->exit_reason = KVM_EXIT_INTR; > > } > > > > + vcpu->mode = IN_GUEST_MODE; > > + smp_mb(); /* ensure vcpu->mode is visible to kvm_vcpu_kick */ > > I think this comment is misleading, because this smp_mb() is really > about ensuring that with respect to other CPUs, the write to vcpu->mode > is observable before the read of kvm_request_pending below, and the > corresponding other barrier is the barrier implied in cmpxchg used by > kvm_vcpu_exiting_guest_mode, which gets called by kvm_vcpu_kick(), which > is called after __kvm_set_request. Agreed > > So this also means that our direct use of kvm_vcpu_kick() without making > a request is currently racy, so we should address that where appropriate > as well. > > Do you feel brave enough to take a look at that? Yup, mission accepted. Thanks, drew _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
