From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Subject: Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work" Date: Mon, 28 Jul 2014 16:16:44 +0200 Message-ID: <20140728161644.00c09b3f@thinkpad-w530> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Christian Borntraeger , KVM , qemu-devel , Cornelia Huck , Paolo Bonzini , Jens Freimann , linux-s390 To: Alexander Graf Return-path: Received: from e06smtp14.uk.ibm.com ([195.75.94.110]:41763 "EHLO e06smtp14.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751175AbaG1OQw (ORCPT ); Mon, 28 Jul 2014 10:16:52 -0400 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 28 Jul 2014 15:16:50 +0100 In-Reply-To: <53D654D2.40308@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: > > On 10.07.14 15:10, Christian Borntraeger wrote: > > From: David Hildenbrand > > > > If a cpu is stopped, it must never be allowed to run and no interrupt may wake it > > up. A cpu also has to be unhalted if it is halted and has work to do - this > > scenario wasn't hit in kvm case yet, as only "disabled wait" is processed within > > QEMU. > > > > Signed-off-by: David Hildenbrand > > Reviewed-by: Cornelia Huck > > Reviewed-by: Christian Borntraeger > > Signed-off-by: Christian Borntraeger > > This looks like it's something that generic infrastructure should take > care of, no? How does this work for the other archs? They always get an > interrupt on the transition between !has_work -> has_work. Why don't we > get one for s390x? > > > Alex > > Well, we have the special case on s390 as a CPU that is in the STOPPED or the CHECK STOP state may never run - even if there is an interrupt. It's basically like this CPU has been switched off. Imagine that it is tried to inject an interrupt into a stopped vcpu. It will kick the stopped vcpu and thus lead to a call to "kvm_arch_process_async_events()". We have to deny that this vcpu will ever run as long as it is stopped. It's like a way to "suppress" the interrupt for such a transition you mentioned. Later, another vcpu might decide to turn that vcpu back on (by e.g. sending a SIGP START to that vcpu). I am not sure if such a mechanism/scenario is applicable to any other arch. They all seem to reset the cs->halted flag if they know they are able to run (e.g. due to an interrupt) - they have no such thing as "stopped cpus", only "halted/waiting cpus". David