On 01/15/2014 10:38 AM, Ingo Molnar wrote:
>
> Right, the fact that most of our MSR accesses today are
> crash-on-failure, which happens to trigger crashes on a regular
> schedule, where most of the crashes are 'harmless' situation except
> that they crash the systems for good.
>
> So I think
* H. Peter Anvin wrote:
> On 01/15/2014 05:36 AM, Borislav Petkov wrote:
> >>
> >> 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
On 01/15/2014 05:36 AM, Borislav Petkov wrote:
>>
>> 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
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.
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
On 01/15/2014 05:36 AM, Borislav Petkov wrote:
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
* H. Peter Anvin h...@linux.intel.com wrote:
On 01/15/2014 05:36 AM, Borislav Petkov wrote:
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
On 01/15/2014 10:38 AM, Ingo Molnar wrote:
Right, the fact that most of our MSR accesses today are
crash-on-failure, which happens to trigger crashes on a regular
schedule, where most of the crashes are 'harmless' situation except
that they crash the systems for good.
So I think
* H. Peter Anvin wrote:
> On 01/14/2014 04:45 PM, tip-bot for Borislav Petkov wrote:
> > + rdmsrl(MSR_AMD64_LS_CFG, val);
> > + if (!(val & BIT(15)))
> > + wrmsrl(MSR_AMD64_LS_CFG, val | BIT(15));
>
> Incidentally, I'm wondering if we shouldn't have a
>
On 01/14/2014 04:45 PM, tip-bot for Borislav Petkov wrote:
> + rdmsrl(MSR_AMD64_LS_CFG, val);
> + if (!(val & BIT(15)))
> + wrmsrl(MSR_AMD64_LS_CFG, val | BIT(15));
Incidentally, I'm wondering if we shouldn't have a
set_in_msr()/clear_in_msr() set of
Commit-ID: 3b56496865f9f7d9bcb2f93b44c63f274f08e3b6
Gitweb: http://git.kernel.org/tip/3b56496865f9f7d9bcb2f93b44c63f274f08e3b6
Author: Borislav Petkov
AuthorDate: Wed, 15 Jan 2014 00:07:11 +0100
Committer: H. Peter Anvin
CommitDate: Tue, 14 Jan 2014 16:39:07 -0800
x86, cpu, amd: Add
Commit-ID: 3b56496865f9f7d9bcb2f93b44c63f274f08e3b6
Gitweb: http://git.kernel.org/tip/3b56496865f9f7d9bcb2f93b44c63f274f08e3b6
Author: Borislav Petkov b...@suse.de
AuthorDate: Wed, 15 Jan 2014 00:07:11 +0100
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 14 Jan 2014
On 01/14/2014 04:45 PM, tip-bot for Borislav Petkov wrote:
+ rdmsrl(MSR_AMD64_LS_CFG, val);
+ if (!(val BIT(15)))
+ wrmsrl(MSR_AMD64_LS_CFG, val | BIT(15));
Incidentally, I'm wondering if we shouldn't have a
set_in_msr()/clear_in_msr() set of
* H. Peter Anvin h...@zytor.com wrote:
On 01/14/2014 04:45 PM, tip-bot for Borislav Petkov wrote:
+ rdmsrl(MSR_AMD64_LS_CFG, val);
+ if (!(val BIT(15)))
+ wrmsrl(MSR_AMD64_LS_CFG, val | BIT(15));
Incidentally, I'm wondering if we shouldn't have a
14 matches
Mail list logo
