On Thu, 18 Jul 2019 at 16:34, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 18/07/19 10:15, Christian Borntraeger wrote: > > > > > > On 18.07.19 09:59, Paolo Bonzini wrote: > >> On 12/07/19 09:15, Wanpeng Li wrote: > >>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > >>> index b4ab59d..2c46705 100644 > >>> --- a/virt/kvm/kvm_main.c > >>> +++ b/virt/kvm/kvm_main.c > >>> @@ -2404,8 +2404,10 @@ void kvm_vcpu_kick(struct kvm_vcpu *vcpu) > >>> int me; > >>> int cpu = vcpu->cpu; > >>> > >>> - if (kvm_vcpu_wake_up(vcpu)) > >>> + if (kvm_vcpu_wake_up(vcpu)) { > >>> + vcpu->preempted = true; > >>> return; > >>> + } > >>> > >>> me = get_cpu(); > >>> if (cpu != me && (unsigned)cpu < nr_cpu_ids && cpu_online(cpu)) > >>> > >> > >> Who is resetting vcpu->preempted to false in this case? This also > >> applies to s390 in fact. > > > > Isnt that done by the sched_in handler? > > I am a bit confused because, if it is done by the sched_in later, I > don't understand why the sched_out handler hasn't set vcpu->preempted > already. > > The s390 commit message is not very clear, but it talks about "a former > sleeping cpu" that "gave up the cpu voluntarily". Does "voluntarily" > that mean it is in kvm_vcpu_block? But then at least for x86 it would see the prepare_to_swait_exlusive() in kvm_vcpu_block(), the task will be set in TASK_INTERRUPTIBLE state, kvm_sched_out will set vcpu->preempted to true iff current->state == TASK_RUNNING. Regards, Wanpeng Li