LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@openvz.org>,
	Dave Jones <davej@redhat.com>,
	linux-kernel@vger.kernel.org, Rudolf Marek <r.marek@assembler.cz>
Subject: Re: [PATCH 1/2] MSR: Add support for safe variants
Date: Mon, 26 Mar 2007 14:09:11 +0200	[thread overview]
Message-ID: <20070326140911.877430f5.khali@linux-fr.org> (raw)
In-Reply-To: <200703261157.l2QBvTJg011821@harpo.it.uu.se>

Hi Mikael,

On Mon, 26 Mar 2007 13:57:29 +0200 (MEST), Mikael Pettersson wrote:
> On Mon, 26 Mar 2007 13:29:37 +0200, Jean Delvare wrote:
> > * * * * * Updated patch * * * * *
> > 
> > From: Rudolf Marek <r.marek@assembler.cz>
> > 
> > Add safe (exception handled) variants of rdmsr_on_cpu and wrmsr_on_cpu.
> > You should use these when the target MSR may not actually exist, as
> > doing so could trigger an exception which the regular functions do not
> > handle. The safe variants are slower, though.
> > 
> > The upcoming coretemp hardware monitoring driver will need this.
> 
> Maybe I'm in the minority here, but I for one strongly believe
> that any attempt to access an MSR "which might not be there" is
> inherently wrong. It implies that your HW detection is incomplete,
> which in combination with MSR accesses means that you may end up
> accessing MSRs that aren't at all what you think they should be.

Hopefully CPU manufacturers are not that stupid and don't implement
MSRs using the same number and doing different things in CPU models
which are otherwise similar enough for one driver to attempt to handle
them both. But of course it's probably only a matter of time before I am
proven wrong...

I agree with you that accessing an MSR which might not be there should
be avoided where possible and only used as a last resort. But until
technical documentation is perfectly correct for all CPUs out there,
there will always be cases where we need to do that.

> Who supplies these imprecise MSR definitions anyway?
> Intel manuals? ACPI?

Intel. Rudolf will know the details better.

-- 
Jean Delvare

  reply	other threads:[~2007-03-26 12:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-26 11:57 Mikael Pettersson
2007-03-26 12:09 ` Jean Delvare [this message]
2007-03-28 21:04   ` Rudolf Marek
  -- strict thread matches above, loose matches on Subject: below --
2007-03-25 12:18 Jean Delvare
2007-03-25 22:22 ` Andrew Morton
2007-03-26 11:29   ` Jean Delvare
2007-03-26 11:55     ` Andrew Morton

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=20070326140911.877430f5.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=adobriyan@openvz.org \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikpe@it.uu.se \
    --cc=r.marek@assembler.cz \
    --subject='Re: [PATCH 1/2] MSR: Add support for safe variants' \
    /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

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).