From: "H. Peter Anvin" <hpa@transmeta.com>
To: Mikael Pettersson <mikpe@csd.uu.se>
Cc: macro@ds2.pg.gda.pl, linux-kernel@vger.kernel.org,
mingo@redhat.com, vandrove@vc.cvut.cz
Subject: Re: [PATCH] Re: UP APIC reenabling vs. cpu type detection ordering
Date: Wed, 07 Feb 2001 21:06:47 -0800 [thread overview]
Message-ID: <3A822967.D42D5165@transmeta.com> (raw)
In-Reply-To: <200102080504.GAA23507@harpo.it.uu.se>
Mikael Pettersson wrote:
>
> H. Peter Anvin wrote:
>
> >"Maciej W. Rozycki" wrote:
> >...
> >> It might be viable just to delete the test altogether, though and just
> >> trap #GP(0) on the MSR access. For the sake of simplicity. If a problem
> >> with a system ever arizes, we may handle it then.
> >>
> >> Note that we still have to choose appropriate vendor-specific PeMo
> >> handling and an event for the NMI watchdog anyway.
> >
> >Right... if that is the case then it seems reasonable.
>
> No, poking into MSRs not explicitly defined on the current CPU is
> inherently unsafe. I have several x86 CPU data sheets here in front
> of me which say the same thing: "Don't write to undocumented MSRs."
> You cannot assume that every single x86 out there stays clear of
> all Intel-defined MSRs. Intel has also expanded this set over time:
> older designs may not even have known about the APIC_BASE MSR.
>
You misread me. "In that case it seems reasonable to do vendor-specific
detection."
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-02-08 5:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-08 5:04 [PATCH] Re: UP APIC reenabling vs. cpu type detection ordering Mikael Pettersson
2001-02-08 5:06 ` H. Peter Anvin [this message]
2001-02-08 11:52 ` Maciej W. Rozycki
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=3A822967.D42D5165@transmeta.com \
--to=hpa@transmeta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@ds2.pg.gda.pl \
--cc=mikpe@csd.uu.se \
--cc=mingo@redhat.com \
--cc=vandrove@vc.cvut.cz \
/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.