All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Jiri Kosina <jikos@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	the arch/x86 maintainers <x86@kernel.org>,
	Pavel Machek <pavel@ucw.cz>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] x86/power: Fix 'nosmt' vs. hibernation triple fault during resume
Date: Fri, 31 May 2019 14:22:27 -0700	[thread overview]
Message-ID: <98E57C7E-24E2-4EB8-A14E-FCA80316F812@amacapital.net> (raw)
In-Reply-To: <nycvar.YFH.7.76.1905312251350.1962@cbobk.fhfr.pm>


> On May 31, 2019, at 2:05 PM, Jiri Kosina <jikos@kernel.org> wrote:
> 
>> On Fri, 31 May 2019, Andy Lutomirski wrote:
>> 
>> The Intel SDM Vol 3 34.10 says:
>> 
>> If the HLT instruction is restarted, the processor will generate a
>> memory access to fetch the HLT instruction (if it is
>> not in the internal cache), and execute a HLT bus transaction. This
>> behavior results in multiple HLT bus transactions
>> for the same HLT instruction.
> 
> Which basically means that both hibernation and kexec have been broken in 
> this respect for gazillions of years, and seems like noone noticed. Makes 
> one wonder what the reason for that might be.
> 
> Either SDM is not precise and the refetch actually never happens for real 
> (or is always in these cases satisfied from I$ perhaps?), or ... ?
> 
> So my patch basically puts things back where they have been for ages 
> (while mwait is obviously much worse, as that gets woken up by the write 
> to the monitored address, which inevitably does happen during resume), but 
> seems like SDM is suggesting that we've been in a grey zone wrt RSM at 
> least for all those ages.
> 
> So perhaps we really should ditch resume_play_dead() altogether 
> eventually, and replace it with sending INIT IPI around instead (and then 
> waking the CPUs properly via INIT INIT START). I'd still like to do that 
> for 5.3 though, as that'd be slightly bigger surgery, and conservatively 
> put things basically back to state they have been up to now for 5.2.
> 


Seems reasonable to me.  I would guess that it mostly works because SMI isn’t all that common and the window where it matters is short.  Or maybe the SDM is misleading.

  reply	other threads:[~2019-05-31 21:22 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28 21:31 [PATCH] x86/power: Fix 'nosmt' vs. hibernation triple fault during resume Jiri Kosina
2019-05-29  8:06 ` Rafael J. Wysocki
2019-05-29  9:03 ` Peter Zijlstra
2019-05-29 10:32 ` [PATCH v2] " Jiri Kosina
2019-05-29 12:02   ` Peter Zijlstra
2019-05-29 16:10   ` Josh Poimboeuf
2019-05-29 16:26     ` Jiri Kosina
2019-05-29 17:00       ` Peter Zijlstra
2019-05-29 17:15         ` Thomas Gleixner
2019-05-29 17:17       ` Josh Poimboeuf
2019-05-29 17:29         ` Jiri Kosina
2019-05-29 18:02           ` Jiri Kosina
2019-05-29 20:26 ` [PATCH v3] " Jiri Kosina
2019-05-29 21:25   ` Pavel Machek
2019-05-29 21:27     ` Jiri Kosina
2019-05-29 21:53       ` Pavel Machek
2019-05-29 22:09 ` [PATCH v4] " Jiri Kosina
2019-05-30  8:46   ` Rafael J. Wysocki
2019-05-30 21:27     ` Thomas Gleixner
2019-05-30 21:38       ` Rafael J. Wysocki
2019-05-30 23:38         ` Josh Poimboeuf
2019-05-30 23:42           ` Jiri Kosina
2019-05-31  5:14             ` Josh Poimboeuf
2019-05-31  8:26               ` Rafael J. Wysocki
2019-05-31  8:47               ` Jiri Kosina
2019-05-31  8:57                 ` Rafael J. Wysocki
2019-05-31 14:24                   ` Andy Lutomirski
2019-05-31 14:31                     ` Jiri Kosina
2019-05-31 14:33                       ` Jiri Kosina
2019-05-31 14:46                       ` Andy Lutomirski
2019-05-31 14:54                         ` Jiri Kosina
2019-05-31 15:26                           ` Josh Poimboeuf
2019-05-31 15:41                             ` Jiri Kosina
2019-05-31 16:19                               ` Josh Poimboeuf
2019-05-31 16:51                                 ` Andy Lutomirski
2019-05-31 18:11                                   ` Josh Poimboeuf
2019-06-03 10:03                                 ` Rafael J. Wysocki
2019-05-31 16:23                           ` Andy Lutomirski
2019-05-31 21:05                             ` Jiri Kosina
2019-05-31 21:22                               ` Andy Lutomirski [this message]
2019-06-03 14:23                                 ` Sean Christopherson
2019-06-03 15:24                                   ` Jiri Kosina
2019-06-03 16:18                                     ` Sean Christopherson
2019-05-31 12:09               ` Jiri Kosina
2019-05-31 14:51               ` Jiri Kosina
2019-05-31 12:18             ` Pavel Machek
2019-05-30 10:47   ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=98E57C7E-24E2-4EB8-A14E-FCA80316F812@amacapital.net \
    --to=luto@amacapital.net \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.