From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751196AbdE3GNG (ORCPT ); Tue, 30 May 2017 02:13:06 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:34534 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750973AbdE3GND (ORCPT ); Tue, 30 May 2017 02:13:03 -0400 Date: Tue, 30 May 2017 16:12:38 +1000 From: Nicholas Piggin To: "Gautham R. Shenoy" Cc: Michael Ellerman , Michael Neuling , Vaidyanathan Srinivasan , Shilpasri G Bhat , Akshay Adiga , Benjamin Herrenschmidt , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/6] powernv:idle: Decouple Timebase restore & Per-core SPRs restore Message-ID: <20170530161238.08a8abe3@roar.ozlabs.ibm.com> In-Reply-To: References: Organization: IBM X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 16 May 2017 14:19:44 +0530 "Gautham R. Shenoy" wrote: > From: "Gautham R. Shenoy" > > On POWER8, in case of > - nap: both timebase and hypervisor state is retained. > - fast-sleep: timebase is lost. But the hypervisor state is retained. > - winkle: timebase and hypervisor state is lost. > > Hence, the current code for handling exit from a idle state assumes > that if the timebase value is retained, then so is the hypervisor > state. Thus, the current code doesn't restore per-core hypervisor > state in such cases. > > But that is no longer the case on POWER9 where we do have stop states > in which timebase value is retained, but the hypervisor state is > lost. So we have to ensure that the per-core hypervisor state gets > restored in such cases. > > Fix this by ensuring that even in the case when timebase is retained, > we explicitly check if we are waking up from a deep stop that loses > per-core hypervisor state (indicated by cr4 being eq or gt), and if > this is the case, we restore the per-core hypervisor state. > > Signed-off-by: Gautham R. Shenoy > --- > arch/powerpc/kernel/idle_book3s.S | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/kernel/idle_book3s.S b/arch/powerpc/kernel/idle_book3s.S > index 4898d67..afd029f 100644 > --- a/arch/powerpc/kernel/idle_book3s.S > +++ b/arch/powerpc/kernel/idle_book3s.S > @@ -731,13 +731,14 @@ timebase_resync: > * Use cr3 which indicates that we are waking up with atleast partial > * hypervisor state loss to determine if TIMEBASE RESYNC is needed. > */ > - ble cr3,clear_lock > + ble cr3,.Ltb_resynced > /* Time base re-sync */ > bl opal_resync_timebase; > /* > - * If waking up from sleep, per core state is not lost, skip to > - * clear_lock. > + * If waking up from sleep (POWER8), per core state > + * is not lost, skip to clear_lock. > */ > +.Ltb_resynced: > blt cr4,clear_lock > > /* It's more that timebase was not lost, rather than resynced. Can we just do a 'bgtl cr3,opal_resync_timebase'? I guess cr4 branch will never be true on POWER9... I think pnv_wakeup_tb_loss is going to end up clearer being split into two between isa 207 and 300. But that can wait until after POWER9 is working properly. Reviewed-by: Nicholas Piggin