linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: mikpe@csd.uu.se
Cc: Dave Jones <davej@codemonkey.org.uk>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] restore sysenter MSRs at resume
Date: Wed, 7 May 2003 07:41:15 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0305070732010.2019-100000@home.transmeta.com> (raw)
In-Reply-To: <16056.53993.774345.897852@gargle.gargle.HOWL>


On Wed, 7 May 2003 mikpe@csd.uu.se wrote:
> 
> The patch below hooks sysenter into the driver model and implements
> a resume() method which restores the sysenter MSRs.

This is wrong.

For one thing, you screw up SMP seriously, by not enabling sysenter on all
CPU's, only the boot one.

For another, we shouldn't have "device drivers" for the CPU. I certainly
agree about restoring the sysenter MSR's, but they should be restored by
the CPU-specific code long _before_ we start initializing devices.

So I think we should just make it part of the CPU initialization (which
should be in two parts: the low-level asm part for the "core" CPU
registers, and then the high-level C part for things like the MSR's, 
user-space segment stuff etc).

So why not just add an explicit call to "cpu_resume()" in one of the 
"do_magic_resume()" things, instead of playing games with device trees..

> The patch has a debug printk() for problematic systems that require
> the fix. If it says your machine didn't preserve the MSRs, please
> post a note about this to LKML with your machine model, so we can
> estimate the scope of the problem.

I really think that it should be done unconditionally - there's no point 
in even _expecting_ the BIOS to restore various random MSR's. I can't 
imagine that many do.

		Linus



  reply	other threads:[~2003-05-07 14:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-06 19:52 [BUG] 2.5.69 oops at sysenter_past_esp mikpe
2003-05-06 22:35 ` Dave Jones
2003-05-07  9:33   ` [PATCH] restore sysenter MSRs at resume mikpe
2003-05-07 14:41     ` Linus Torvalds [this message]
2003-05-07 17:23       ` mikpe
2003-05-07 17:39         ` Linus Torvalds
2003-05-08 21:47           ` Pavel Machek
2003-05-10 16:41 mikpe
2003-05-11 19:01 ` Linus Torvalds
2003-05-11 19:08   ` Pavel Machek
2003-05-11 19:28     ` Nigel Cunningham
2003-05-12 11:30       ` Pavel Machek
2003-05-12 19:33         ` Nigel Cunningham
2003-05-12 19:54           ` Pavel Machek
2003-05-11 21:04   ` Alan Cox
2003-05-12  0:07     ` Linus Torvalds
2003-05-12 11:13       ` Alan Cox
2003-05-12 20:15       ` 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=Pine.LNX.4.44.0305070732010.2019-100000@home.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=davej@codemonkey.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikpe@csd.uu.se \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).