From nobody Mon Feb 9 03:13:41 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@gnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@gnu.org Return-Path: Received: from lists.gnu.org (208.118.235.17 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1506632469043869.9655748518417; Thu, 28 Sep 2017 14:01:09 -0700 (PDT) Received: from localhost ([::1]:60887 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxfvW-0007Iu-1j for importer@patchew.org; Thu, 28 Sep 2017 17:00:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxfaY-0005G7-Vh for qemu-devel@nongnu.org; Thu, 28 Sep 2017 16:39:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxfaU-0003os-Vg for qemu-devel@nongnu.org; Thu, 28 Sep 2017 16:39:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37984) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dxfaU-0003oT-Pg for qemu-devel@nongnu.org; Thu, 28 Sep 2017 16:39:14 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C132F859F7; Thu, 28 Sep 2017 20:39:13 +0000 (UTC) Received: from t460s.redhat.com (ovpn-116-18.ams2.redhat.com [10.36.116.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id 87E1F18C79; Thu, 28 Sep 2017 20:39:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C132F859F7 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=david@redhat.com From: David Hildenbrand To: qemu-devel@nongnu.org Date: Thu, 28 Sep 2017 22:37:08 +0200 Message-Id: <20170928203708.9376-31-david@redhat.com> In-Reply-To: <20170928203708.9376-1-david@redhat.com> References: <20170928203708.9376-1-david@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 28 Sep 2017 20:39:13 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v2 30/30] target/s390x: special handling when starting a CPU with WAIT PSW X-BeenThere: qemu-devel@gnu.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 Hildenbrand , cohuck@redhat.com, Richard Henderson , Alexander Graf , Christian Borntraeger Errors-To: qemu-devel-bounces+importer=patchew.org@gnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" When we try to start a CPU with a WAIT PSW, we have to take care that TCG will actually try to continue executing instructions. We must therefore really only unhalt the CPU if we don't have a WAIT PSW. Also document the special order for restart interrupts, which load a new PSW and change the state to operating. To keep KVM working, simply don't have a look at the WAIT bit when loading the PSW. Otherwise the behavior of a restart interrupt when a CPU stopped would be changed. Signed-off-by: David Hildenbrand Reviewed-by: Richard Henderson --- target/s390x/cpu.c | 11 +++++++++-- target/s390x/sigp.c | 6 +++++- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c index e27827afb3..981f5d4f39 100644 --- a/target/s390x/cpu.c +++ b/target/s390x/cpu.c @@ -335,8 +335,15 @@ unsigned int s390_cpu_set_state(uint8_t cpu_state, S39= 0CPU *cpu) break; case CPU_STATE_OPERATING: case CPU_STATE_LOAD: - /* unhalt the cpu for common infrastructure */ - s390_cpu_unhalt(cpu); + /* + * Starting a CPU with a PSW WAIT bit set: + * KVM: handles this internally and triggers another WAIT exit. + * TCG: will actually try to continue to run. Don't unhalt, will + * be done when the CPU actually has work (an interrupt). + */ + if (!tcg_enabled() || !(cpu->env.psw.mask & PSW_MASK_WAIT)) { + s390_cpu_unhalt(cpu); + } break; default: error_report("Requested CPU state is not a valid S390 CPU state: %= u", diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c index 964c75a736..ac3f8e7dc2 100644 --- a/target/s390x/sigp.c +++ b/target/s390x/sigp.c @@ -232,8 +232,12 @@ static void sigp_restart(CPUState *cs, run_on_cpu_data= arg) case CPU_STATE_STOPPED: /* the restart irq has to be delivered prior to any other pending = irq */ cpu_synchronize_state(cs); - do_restart_interrupt(&cpu->env); + /* + * Set OPERATING (and unhalting) before loading the restart PSW. + * load_psw() will then properly halt the CPU again if necessary (= TCG). + */ s390_cpu_set_state(CPU_STATE_OPERATING, cpu); + do_restart_interrupt(&cpu->env); break; case CPU_STATE_OPERATING: cpu_inject_restart(cpu); --=20 2.13.5