[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPE
From: |
David Hildenbrand |
Subject: |
Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work" |
Date: |
Tue, 29 Jul 2014 17:06:36 +0200 |
> Il 28/07/2014 17:03, David Hildenbrand ha scritto:
> > Well the difference is, that a STOPPED vcpu can be woken up by non-interrupt
> > like things (SIGP START) AND a special interrupt (SIGP RESTART - which is
> > like
> > a "SIPI"++ as it performs a psw exchange - "NMI"). So we basically have two
> > paths that can lead to a state change. All interrupt bits may be in any
> > combination (SIGP RESTART interrupts can't be masked out, nor can SIGP
> > START be
> > denied).
> >
> > The other thing may be that on s390, each vcpu (including itself) can put
> > another vcpu into the STOPPED state - I assume that this is different for
> > x86 "
> > INIT_RECEIVED". For this reason we have to watch out for bad race conditions
> > (e.g. multiple vcpus working on another vcpu)...
>
> You can do that in x86 by sending an INIT inter-processor interrupt. A
> SIPI is ignored if the CPU is not in INIT_RECEIVED state.
>
> Commit 66450a21f99636af4fafac2afd33f1a40631bc3a introduced the current
> implementation.
>
> - an INIT cancels a previous SIPI;
>
> - if both INIT and SIPI are sent, on real hardware you need to have a
> few hundred microseconds between them, but KVM will reliably process
> INIT before SIPI.
>
> See commit 299018f44ac553dce3caf84df1d14c4764faa279 for an example of
> the races that can happen.
>
> Note that x86 has KVM_MP_STATE_SIPI_RECEIVED state but it is obsolete,
> we go straight from KVM_MP_STATE_INIT_RECEIVED to KVM_MP_STATE_RUNNABLE.
>
Thanks for the explanation Paolo!
Looks like from an interrupt point of view, the states have a lot in common.
The major thing that differs on s390 is probably the way these interrupts are
generated and what else they influence (all the power of the SIGP facility :)
+ special check-stop state that can't be left by an interrupt, only by SIGP
CPU resets).
David
- [Qemu-devel] [PATCH/RFC 3/5] s390x/kvm: proper use of the cpu states OPERATING and STOPPED, (continued)
- [Qemu-devel] [PATCH/RFC 3/5] s390x/kvm: proper use of the cpu states OPERATING and STOPPED, Christian Borntraeger, 2014/07/10
- [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work", Christian Borntraeger, 2014/07/10
- Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work", Alexander Graf, 2014/07/28
- Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work", David Hildenbrand, 2014/07/28
- Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work", Paolo Bonzini, 2014/07/28
- Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work", Alexander Graf, 2014/07/28
- Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work", David Hildenbrand, 2014/07/28
- Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work", David Hildenbrand, 2014/07/28
- Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work", Alexander Graf, 2014/07/28
- Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work", Paolo Bonzini, 2014/07/29
- Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work",
David Hildenbrand <=
- Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work", Christian Borntraeger, 2014/07/29
- Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work", Alexander Graf, 2014/07/29
- Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work", David Hildenbrand, 2014/07/31