Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2368352imm; Thu, 19 Jul 2018 19:34:19 -0700 (PDT) X-Google-Smtp-Source: AAOMgpczreW5OCyDg/VDJkvFcDyEf+xRwihr4olD8tiWnFNHJpj8DoaFiEHS940FpJxirx4xAb6I X-Received: by 2002:a62:9042:: with SMTP id a63-v6mr274827pfe.52.1532054059672; Thu, 19 Jul 2018 19:34:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532054059; cv=none; d=google.com; s=arc-20160816; b=gRKCGRKVRvGYLIQAhrMneNVdaX3F5qGj09/c2fB7M/DFblDDAXHn81mJauQN+WqTYT EbyBoBcWzxsywpurfF0J/XC07njICgyqlQJxx6TE7CCnHDBJAz3/nwIxji4Us/gSTphp gP0E88REjcCi/6en/eg9qKWRSA9YcB+1mpQO5wo7o7GsivFmdUjwdOR58wHGfXrDAgHm xmnPlqcVmR7gE6tNo8uwjMO4WDB0G96NDbCeuOvtSJj/lBzDc+Pz9SLryHPuSBsX8eXQ lpA6edwnZuCkTvGqKxUEZKdz/19a+EUc15g4q3yZGwo5UW6llthg7dIAyz23fxstK4+U 89nA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:arc-authentication-results; bh=/hksh0t8bgkmXFylYpZKCnqbfUUI+Ospu+WvFHhbJg8=; b=QNOEca/7iS692y/N/9Z+a/YSdjf2yRJ3W61oQVIKfUOHyqoh2V85fDtFcmZVVvSWBs Gc0Z4heC9IAPCM5dVeI6yIS7OUIjKgPRzv7fboEJqULgEkAuQ5LhSEQYjGz4a4sPO0m9 2lasH/t9+pI41awHgIr0Ie4b7vbXN9cH/4onQEFiRsWZyMQ5iyBW9M7lIjas1K+PA0+h n5bXIpJc+6IRJeDHsVJBA2pw6V/EYAVjaL3hpzyoTvrOVVgu7BPkIvLEYclY3OSF+30L UIn7svBO1UrieiqN5zN610FMvTQRwEIYddJz85mYj62NYxLvD5W1bzg0ulqFbhO84XG7 l69w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 33-v6si698975plk.299.2018.07.19.19.33.50; Thu, 19 Jul 2018 19:34:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730933AbeGTDSt (ORCPT + 99 others); Thu, 19 Jul 2018 23:18:49 -0400 Received: from ozlabs.org ([203.11.71.1]:55609 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730770AbeGTDSt (ORCPT ); Thu, 19 Jul 2018 23:18:49 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 41Ww0K4tWwz9s4s; Fri, 20 Jul 2018 12:32:49 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Michael Neuling , ego@linux.vnet.ibm.com Cc: Benjamin Herrenschmidt , Vaidyanathan Srinivasan , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Florian Weimer , "Oleg Nesterov" Subject: Re: [RESEND][PATCH] powerpc/powernv : Save/Restore SPRG3 on entry/exit from stop. In-Reply-To: <1205bfc10c62986b4345fa258cf37e820c08226b.camel@neuling.org> References: <1531826849-31838-1-git-send-email-ego@linux.vnet.ibm.com> <1531843216-22209-1-git-send-email-ego@linux.vnet.ibm.com> <80bbdf47081e3e302ab5f28b5ddc9e2faabba842.camel@neuling.org> <20180718081249.GA17700@in.ibm.com> <1205bfc10c62986b4345fa258cf37e820c08226b.camel@neuling.org> Date: Fri, 20 Jul 2018 12:32:43 +1000 Message-ID: <87tvoubpro.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michael Neuling writes: > On Wed, 2018-07-18 at 13:42 +0530, Gautham R Shenoy wrote: >> On Wed, Jul 18, 2018 at 09:24:19AM +1000, Michael Neuling wrote: >> > >> > > DEFINE(PPC_DBELL_SERVER, PPC_DBELL_SERVER); >> > > diff --git a/arch/powerpc/kernel/idle_book3s.S >> > > b/arch/powerpc/kernel/idle_book3s.S >> > > index d85d551..5069d42 100644 >> > > --- a/arch/powerpc/kernel/idle_book3s.S >> > > +++ b/arch/powerpc/kernel/idle_book3s.S >> > > @@ -120,6 +120,9 @@ power9_save_additional_sprs: >> > > mfspr r4, SPRN_MMCR2 >> > > std r3, STOP_MMCR1(r13) >> > > std r4, STOP_MMCR2(r13) >> > > + >> > > + mfspr r3, SPRN_SPRG3 >> > > + std r3, STOP_SPRG3(r13) >> > >> > We don't need to save it. Just restore it from paca->sprg_vdso which should >> > never change. >> >> Ok. I will respin a patch to restore SPRG3 from paca->sprg_vdso. >> >> > >> > How can we do better at catching these missing SPRGs? >> >> We can go through the list of SPRs from the POWER9 User Manual and >> document explicitly why we don't have to save/restore certain SPRs >> during the execution of the stop instruction. Does this sound ok ? >> >> (Ref: Table 4-8, Section 4.7.3.4 from the POWER9 User Manual >> accessible from >> https://openpowerfoundation.org/?resource_lib=power9-processor-users-manual) > > I was thinking of a boot time test case built into linux. linux has some boot > time test cases which you can enable via CONFIG options. > > Firstly you could see if an SPR exists using the same trick xmon does in > dump_one_spr(). Then once you have a list of usable SPRs, you could write all > the known ones (I assume you'd have to leave out some, like the PSSCR), then set Write what value? Ideally you want to write a random bit pattern to reduce the chance that only some bits are being restored. But you can't do that because writing a value to an SPRs has an effect. Some of them might even need to be zero, in which case you can't really distinguish that from a non-restored zero. > the appropriate stop level, make sure you got into that stop level, and then see > if that register was changed. Then you'd have an automated list of registers you > need to make sure you save/restore at each stop level. > > Could something like that work? Maybe. Ignoring the problem of whether you can write a meaningful value to some of the SPRs, I'm not entirely convinced it's going to work. But maybe I'm wrong. But there's a much simpler solution, we should 1) have a selftest for getcpu() and 2) we should be running the glibc (I think?) test suite that found this in the first place. It's frankly embarrassing that we didn't find this. cheers