[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190531152626.4nmyc7lj6mjwuo2v@treble>
Date: Fri, 31 May 2019 10:26:26 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Jiri Kosina <jikos@...nel.org>
Cc: Andy Lutomirski <luto@...capital.net>,
Andy Lutomirski <luto@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
the arch/x86 maintainers <x86@...nel.org>,
Pavel Machek <pavel@....cz>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Linux PM <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] x86/power: Fix 'nosmt' vs. hibernation triple fault
during resume
On Fri, May 31, 2019 at 04:54:20PM +0200, Jiri Kosina wrote:
> On Fri, 31 May 2019, Andy Lutomirski wrote:
>
> > For that matter, what actually happens if we get an SMI while halted?
> > Does RSM go directly to sleep or does it re-fetch the HLT?
>
> Our mails just crossed, I replied to Josh's mwait() proposal patch a
> minute ago.
Good catch. I agree that mwait seems unsafe across resume and my patch
is bogus.
Andy, in the short term it sounds like you're proposing to make
native_play_dead() use hlt_play_dead() unconditionally. Right?
That would simplify things and also would fix Jiri's bug I think. The
only question I'd have is if we have data on the power savings
difference between hlt and mwait. mwait seems to wake up on a lot of
different conditions which might negate its deeper sleep state.
Andy, for your long term idea to use INIT IPI, I wonder if that would
work with SMT siblings? Specifically I wonder about the Intel issue
that requires siblings to have CR4.MCE set.
--
Josh
Powered by blists - more mailing lists