From patchwork Fri Feb 9 09:25:03 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cornelia Huck X-Patchwork-Id: 10208599 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1668360245 for ; Fri, 9 Feb 2018 09:36:57 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 16885297F6 for ; Fri, 9 Feb 2018 09:36:57 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0A3102981E; Fri, 9 Feb 2018 09:36:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id A1534297F6 for ; Fri, 9 Feb 2018 09:36:56 +0000 (UTC) Received: from localhost ([::1]:52997 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ek571-0003gW-Nf for patchwork-qemu-devel@patchwork.kernel.org; Fri, 09 Feb 2018 04:36:55 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ek4wK-0001ze-Kq for qemu-devel@nongnu.org; Fri, 09 Feb 2018 04:25:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ek4wH-000615-Ek for qemu-devel@nongnu.org; Fri, 09 Feb 2018 04:25:52 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:53010 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ek4wH-00060k-A6; Fri, 09 Feb 2018 04:25:49 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DF96A40265F6; Fri, 9 Feb 2018 09:25:48 +0000 (UTC) Received: from localhost (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 99145B350D; Fri, 9 Feb 2018 09:25:48 +0000 (UTC) From: Cornelia Huck To: peter.maydell@linaro.org Date: Fri, 9 Feb 2018 10:25:03 +0100 Message-Id: <20180209092524.31348-9-cohuck@redhat.com> In-Reply-To: <20180209092524.31348-1-cohuck@redhat.com> References: <20180209092524.31348-1-cohuck@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Fri, 09 Feb 2018 09:25:48 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Fri, 09 Feb 2018 09:25:48 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'cohuck@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PULL 08/29] s390x/tcg: tolerate wrong wakeups due to floating interrupts X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: thuth@redhat.com, david@redhat.com, Cornelia Huck , qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, qemu-s390x@nongnu.org, rth@twiddle.net Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP From: David Hildenbrand This is a preparation for floating interrupt support and only applies to MTTCG, single threaded TCG works just fine. If a floating interrupt wakes up a VCPU and the CPU thinks it can run (clearing cs->halted), at the point where the interrupt would be delivered, already another VCPU might have picked up the interrupt, resulting in a wakeup without an interrupt (executing wrong code). It is wrong to let the VCPU continue to execute (the WAIT PSW). Instead, we have to put the VCPU back to sleep. Signed-off-by: David Hildenbrand Message-Id: <20180129125623.21729-8-david@redhat.com> Signed-off-by: Cornelia Huck --- target/s390x/excp_helper.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/target/s390x/excp_helper.c b/target/s390x/excp_helper.c index 0cbc4051d1..23447af942 100644 --- a/target/s390x/excp_helper.c +++ b/target/s390x/excp_helper.c @@ -503,6 +503,11 @@ bool s390_cpu_exec_interrupt(CPUState *cs, int interrupt_request) s390_cpu_do_interrupt(cs); return true; } + if (env->psw.mask & PSW_MASK_WAIT) { + /* Woken up because of a floating interrupt but it has already + * been delivered. Go back to sleep. */ + cpu_interrupt(CPU(cpu), CPU_INTERRUPT_HALT); + } } return false; }