Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752204AbdDMKFF convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Thu, 13 Apr 2017 06:05:05 -0400
Received: from ozlabs.org ([103.22.144.67]:56191 "EHLO ozlabs.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750765AbdDMKFD (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 13 Apr 2017 06:05:03 -0400
From: Michael Ellerman <mpe@ellerman.id.au>
To: Nicholas Piggin <npiggin@gmail.com>,
        Michael Neuling <mikey@neuling.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
        "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>,
        "Shreyas B. Prabhu" <shreyasbp@gmail.com>,
        Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>,
        Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
        Anton Blanchard <anton@samba.org>,
        Balbir Singh <bsingharora@gmail.com>,
        Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>,
        Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>,
        linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] powernv:idle: Set LPCR_UPRT on wakeup from deep-stop
In-Reply-To: <20170413171817.2854f597@roar.ozlabs.ibm.com>
References: <cover.1491996797.git.ego@linux.vnet.ibm.com> <9be8410e0abe5ae1afa16a6f987c53046ef51757.1491996797.git.ego@linux.vnet.ibm.com> <8737ddq7py.fsf@skywalker.in.ibm.com> <1492056725.7236.95.camel@kernel.crashing.org> <1492064854.4624.48.camel@neuling.org> <20170413171817.2854f597@roar.ozlabs.ibm.com>
User-Agent: Notmuch/0.21 (https://notmuchmail.org)
Date: Thu, 13 Apr 2017 20:05:01 +1000
Message-ID: <878tn4aaia.fsf@concordia.ellerman.id.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1643
Lines: 44

Nicholas Piggin <npiggin@gmail.com> writes:

> On Thu, 13 Apr 2017 16:27:34 +1000
> Michael Neuling <mikey@neuling.org> wrote:
>
>> On Thu, 2017-04-13 at 14:12 +1000, Benjamin Herrenschmidt wrote:
>> > On Thu, 2017-04-13 at 09:28 +0530, Aneesh Kumar K.V wrote:  
>> > > >   #endif
>> > > >        mtctr   r12
>> > > >        bctrl
>> > > > +/*
>> > > > + * cur_cpu_spec->cpu_restore would restore LPCR to a
>> > > > + * sane value that is set at early boot time,
>> > > > + * thereby clearing LPCR_UPRT.
>> > > > + * LPCR_UPRT is required if we are running in Radix mode.
>> > > > + * Set it here if that be the case.
>> > > > + */
>> > > > +BEGIN_MMU_FTR_SECTION
>> > > > +     mfspr   r3, SPRN_LPCR
>> > > > +     LOAD_REG_IMMEDIATE(r4, LPCR_UPRT)
>> > > > +     or      r3, r3, r4
>> > > > +     mtspr   SPRN_LPCR, r3
>> > > > +END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_RADIX)  
>> > 
>> > We are probably better off saving the value somewhere during boot
>> > and just "blasting" it whole back.  
>> 
>> We seem to touch LPCR in a bunch of places these days.  Not sure when "sometimes
>>  during boot" should actually be.
>
> In the short term, what if we just save LPCR and restore it after calling
> cpu_restore? As you say there are a lot of things that touch LPCR we're
> not catching here.

Yeah can we save it on the way down and restore that value on the way
back up?

The real problem here is that cpu_restore() does not "restore" anything,
it programs a set of fixed values.

We should probably rework it so that it actually does a save/restore to
avoid more bugs like this.

cheers