From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCl3A-0002Uu-Dc for qemu-devel@nongnu.org; Thu, 31 Jul 2014 03:45:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XCl31-0004tm-CA for qemu-devel@nongnu.org; Thu, 31 Jul 2014 03:45:20 -0400 Received: from e06smtp16.uk.ibm.com ([195.75.94.112]:33412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCl31-0004tY-3P for qemu-devel@nongnu.org; Thu, 31 Jul 2014 03:45:11 -0400 Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 31 Jul 2014 08:45:08 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 048352190056 for ; Thu, 31 Jul 2014 08:44:51 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s6V7j6fB35717270 for ; Thu, 31 Jul 2014 07:45:06 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s6V7j4uW021937 for ; Thu, 31 Jul 2014 01:45:05 -0600 Date: Thu, 31 Jul 2014 09:45:01 +0200 From: David Hildenbrand Message-ID: <20140731094501.31d8a047@thinkpad-w530> In-Reply-To: <53D78A44.1060706@suse.de> 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> <53D78937.3010307@de.ibm.com> <53D78A44.1060706@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Alexander Graf Cc: linux-s390 , KVM , qemu-devel , Christian Borntraeger , Jens Freimann , Cornelia Huck , Paolo Bonzini > > We have > > - wait (wait bit in PSW) > > - disabled wait (wait bit and interrupt fencing in PSW) > > - STOPPED (not related to PSW, state change usually handled via service processor or hypervisor) > > > > I think we have to differentiate between KVM/TCG. On KVM we always do in kernel halt and qemu sees a halted only for STOPPED or disabled wait. TCG has to take care of the normal wait as well. > > > > From a first glimpse, a disabled wait and STOPPED look similar, but there are (important) differences, e.g. other CPUs get a different a different result from a SIGP SENSE. This makes a big difference, e.g. for Linux guests, that send a SIGP STOP, followed by a SIGP SENSE loop until the CPU is down on hotplug (and shutdown, kexec..) So I think we agree, that handling the cpu states natively makes sense. > > > > The question is now only how to model it correctly without breaking TCG/KVM and reuse as much common code as possible. Correct? > > > > Do I understand you correctly, that your collapsing of stopped and halted is only in the qemu coding sense, IOW maybe we could just modify kvm_arch_process_async_events to consider the STOPPED state, as TCGs sigp implementation does not support SMP anyway? > > That works for me, yes. > > > Alex > I had a look at it yesterday and it seems like we can totally drop this patch: 1. TCG doesn't support multiple CPUs and the TCG SIGP implementation isn't ready for proper STOP/START/SENSE. Testing for STOPPED cpus in cpu_has_work() can be dropped. To be able to support TCG was the main reason for this patch - as we don't want to do so for now, we can leave it as is. We can still decide to support the cpu states later using a mechanism suggest by Alex (interrupt_requests). Even if cpu_has_work() would make cpu.c:cpu_thread_is_idle() return false, kvm_arch_process_async_events() called by kvm-all.c:kvm_cpu_exec() would make it go back to sleep. Therefore a stopped VCPU will never be able to run in the KVM case (because it always has cs->halted = true). 2. The unhalt in kvm_arch_process_async_events is for a special case where a VCPU is in disabled wait and receives e.g. a machine-check interrupt. These might happen in the future, for now we will never see them (the only way to get a vcpu out of disabled wait are SIGP RESTART/CPU RESET - so we don't break anything at that point). David