From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XC7pD-00066Q-O6 for qemu-devel@nongnu.org; Tue, 29 Jul 2014 09:52:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XC7p6-0007Ge-8c for qemu-devel@nongnu.org; Tue, 29 Jul 2014 09:52:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XC7p5-0007Ga-W1 for qemu-devel@nongnu.org; Tue, 29 Jul 2014 09:52:12 -0400 Message-ID: <53D7A700.8090207@redhat.com> Date: Tue, 29 Jul 2014 15:52:00 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1404997839-29038-1-git-send-email-borntraeger@de.ibm.com> <1404997839-29038-5-git-send-email-borntraeger@de.ibm.com> <53D654D2.40308@suse.de> <20140728161644.00c09b3f@thinkpad-w530> <2B39547D-B9A3-4509-808C-B0808067ED54@suse.de> <20140728170318.1eb8ed64@thinkpad-w530> In-Reply-To: <20140728170318.1eb8ed64@thinkpad-w530> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Hildenbrand , Alexander Graf Cc: linux-s390 , KVM , qemu-devel , Christian Borntraeger , Jens Freimann , Cornelia Huck 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.