From patchwork Mon Oct 9 15:49:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?C=C3=A9dric_Le_Goater?= X-Patchwork-Id: 823309 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3y9l8q0NQlz9tXy for ; Tue, 10 Oct 2017 02:51:23 +1100 (AEDT) Received: from localhost ([::1]:58478 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1aKv-0004na-4L for incoming@patchwork.ozlabs.org; Mon, 09 Oct 2017 11:51:21 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1aJm-0004Q4-0J for qemu-devel@nongnu.org; Mon, 09 Oct 2017 11:50:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e1aJi-0003Oz-Sg for qemu-devel@nongnu.org; Mon, 09 Oct 2017 11:50:10 -0400 Received: from 2.mo4.mail-out.ovh.net ([46.105.72.36]:43098) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e1aJi-0003OH-Mj for qemu-devel@nongnu.org; Mon, 09 Oct 2017 11:50:06 -0400 Received: from player746.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo4.mail-out.ovh.net (Postfix) with ESMTP id 39E8DD968B for ; Mon, 9 Oct 2017 17:50:05 +0200 (CEST) Received: from zorba.kaod.org.com (LFbn-1-2231-173.w90-76.abo.wanadoo.fr [90.76.52.173]) (Authenticated sender: clg@kaod.org) by player746.ha.ovh.net (Postfix) with ESMTPSA id 07BAE500087; Mon, 9 Oct 2017 17:49:59 +0200 (CEST) From: =?utf-8?q?C=C3=A9dric_Le_Goater?= To: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, David Gibson , Nikunj A Dadhania , Benjamin Herrenschmidt Date: Mon, 9 Oct 2017 17:49:30 +0200 Message-Id: <20171009154930.29095-5-clg@kaod.org> X-Mailer: git-send-email 2.13.6 In-Reply-To: <20171009154930.29095-1-clg@kaod.org> References: <20171009154930.29095-1-clg@kaod.org> MIME-Version: 1.0 X-Ovh-Tracer-Id: 11145564656128592723 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelledrleelgdejkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 46.105.72.36 Subject: [Qemu-devel] [PATCH v2 4/4] spapr/rtas: do not reset the MSR in stop-self command 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: =?utf-8?q?C=C3=A9dric_Le_Goater?= Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" When a CPU is stopped with the 'stop-self' RTAS call, its state 'halted' is switched to 1 and, in this case, the MSR is not taken into account anymore in the cpu_has_work() routine. Only the pending hardware interrupts are checked with their LPCR:PECE* enablement bit. The CPU is now also protected from the decrementer interrupt by the LPCR:PECE* bits which are disabled in the 'stop-self' RTAS call. Reseting the MSR is pointless. Signed-off-by: Cédric Le Goater Reviewed-by: David Gibson --- hw/ppc/spapr_rtas.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c index dfdbf1e2c6f8..dc825bc58263 100644 --- a/hw/ppc/spapr_rtas.c +++ b/hw/ppc/spapr_rtas.c @@ -210,16 +210,6 @@ static void rtas_stop_self(PowerPCCPU *cpu, sPAPRMachineState *spapr, cs->halted = 1; qemu_cpu_kick(cs); - /* - * While stopping a CPU, the guest calls H_CPPR which - * effectively disables interrupts on XICS level. - * However decrementer interrupts in TCG can still - * wake the CPU up so here we disable interrupts in MSR - * as well. - * As rtas_start_cpu() resets the whole MSR anyway, there is - * no need to bother with specific bits, we just clear it. - */ - env->msr = 0; /* Don't let the decremeter run on a CPU being stopped. This could * deliver an interrupt on a dying CPU and crash the guest.