mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, aravind.gopalakrishnan@amd.com,
	tglx@linutronix.de, bp@suse.de, hpa@linux.intel.com,
	linux-tip-commits@vger.kernel.org
Subject: Re: [tip:x86/urgent] x86, cpu, amd: Add workaround for family 16h, erratum 793
Date: Wed, 15 Jan 2014 14:36:19 +0100	[thread overview]
Message-ID: <20140115133619.GA32051@pd.tnic> (raw)
In-Reply-To: <20140115062817.GA11869@gmail.com>

On Wed, Jan 15, 2014 at 07:28:17AM +0100, Ingo Molnar wrote:
> > The perhaps only question is if it should be "set/clear_bit_in_msr()"
> > rather than having to haul a full 64-bit mask in the common case.

I'd prefer the _bit() variant because it is easy to use in all those
set-chicken-bit cases.

> I'd suggest the introduction of a standard set of methods operating on 
> MSRs:
> 
> 	msr_read()
> 	msr_write()
> 	msr_set_bit()
> 	msr_clear_bit()
> 	msr_set_mask()
> 	msr_clear_mask()
> 
> etc.
> 
> msr_read() would essentially map to rdmsr_safe(). Each method has a
> return value that can be checked for failure.

I'm not sure we want to use the _safe() variants by default as it would
generate the exception tables even in cases where they're clearly not
needed.

> Note that the naming of 'msr_set_bit()' and 'msr_clear_bit()' mirrors
> that of bitops, and set_mask/clear_mask is named along a similar
> pattern, so that it's more immediately obvious what's going on.

Yes, I completely agree - this is something I will do after the merge
window.

The question about the need for the _mask() variants will be best
answered after going over the sources and checking whether there
actually is a need for setting more than one bit in an MSR.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2014-01-15 13:36 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-14 11:41 AMD errata 793 (CVE-2013-6885) needs a workaround in Linux? Henrique de Moraes Holschuh
2014-01-14 11:55 ` Borislav Petkov
2014-01-14 15:14   ` H. Peter Anvin
2014-01-14 15:35     ` Borislav Petkov
2014-01-14 16:27       ` [PATCH] x86, CPU, AMD: Add workaround for family 16h, erratum 793 Borislav Petkov
2014-01-14 16:30         ` H. Peter Anvin
2014-01-14 16:42           ` Borislav Petkov
2014-01-14 17:46             ` H. Peter Anvin
2014-01-14 23:07               ` [PATCH -v1.1] " Borislav Petkov
2014-01-15  0:38                 ` H. Peter Anvin
2014-01-15 11:10                   ` [PATCH -v1.2] " Borislav Petkov
2014-01-15  0:45                 ` [tip:x86/urgent] x86, cpu, amd: " tip-bot for Borislav Petkov
2014-01-15  0:54                   ` H. Peter Anvin
2014-01-15  6:28                     ` Ingo Molnar
2014-01-15 13:36                       ` Borislav Petkov [this message]
2014-01-15 13:52                         ` H. Peter Anvin
2014-01-15 18:38                           ` Ingo Molnar
2014-01-16  4:11                             ` H. Peter Anvin
     [not found]         ` <52D59ACC.3090100@amd.com>
2014-01-14 20:38           ` [PATCH] x86, CPU, AMD: " Borislav Petkov
2014-01-16 17:58             ` Aravind Gopalakrishnan
2014-01-16 18:10               ` Borislav Petkov
2014-01-17  0:21               ` Henrique de Moraes Holschuh
2014-01-17  0:25                 ` H. Peter Anvin
2014-01-17 10:18                 ` Borislav Petkov
2014-01-17 16:23                   ` H. Peter Anvin
2014-01-17 17:02                     ` Borislav Petkov
2014-01-17 17:36                       ` Aravind Gopalakrishnan
2014-01-17 17:42                       ` H. Peter Anvin
2014-01-17 18:05                         ` Aravind Gopalakrishnan
2014-01-17 18:25                           ` Borislav Petkov
2014-01-17 22:28         ` Pavel Machek
2014-01-17 22:50           ` Borislav Petkov
2014-01-17 22:51             ` H. Peter Anvin
2014-01-17 22:57               ` Borislav Petkov
2014-01-18  0:29               ` Pavel Machek
2014-01-18  1:21                 ` H. Peter Anvin
2014-01-18  2:01                   ` Pavel Machek
2014-01-18 10:42                     ` Borislav Petkov
2014-01-18 11:08                       ` Pavel Machek
2014-01-18 11:26                         ` Borislav Petkov
2014-01-18 11:31                           ` 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=20140115133619.GA32051@pd.tnic \
    --to=bp@suse.de \
    --cc=aravind.gopalakrishnan@amd.com \
    --cc=hpa@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    /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

Powered by JetHome