* Andy Lutomirski wrote:
> On Thu, Oct 1, 2015 at 12:15 AM, Ingo Molnar wrote:
> >
> > * Andy Lutomirski wrote:
> >
> >> > These could still be open coded in an inlined fashion, like the
> >> > scheduler usage.
> >>
> >> We could have a raw_rdmsr for those.
> >>
> >> OTOH, I'm still not 100%
On Thu, Oct 1, 2015 at 12:15 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> > These could still be open coded in an inlined fashion, like the scheduler
>> > usage.
>>
>> We could have a raw_rdmsr for those.
>>
>> OTOH, I'm still not 100% convinced that this warn-but-don't-die behavior
* Andy Lutomirski wrote:
> > These could still be open coded in an inlined fashion, like the scheduler
> > usage.
>
> We could have a raw_rdmsr for those.
>
> OTOH, I'm still not 100% convinced that this warn-but-don't-die behavior is
> worth the effort. This isn't a frequent source of bugs
On 09/21/2015 09:36 AM, Linus Torvalds wrote:
>
> How many msr reads are so critical that the function call
> overhead would matter? Get rid of the inline version of the _safe()
> thing too, and put that thing there too.
>
Probably only the ones that may go in the context switch path.
-
On Wed, Sep 30, 2015 at 7:01 AM, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
>> On Mon, Sep 21, 2015 at 09:36:15AM -0700, Linus Torvalds wrote:
>> > On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
>> > >
>> > > Linus, what's your preference?
>> >
>> > So quite frankly, is there any reas
* Peter Zijlstra wrote:
> On Mon, Sep 21, 2015 at 09:36:15AM -0700, Linus Torvalds wrote:
> > On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
> > >
> > > Linus, what's your preference?
> >
> > So quite frankly, is there any reason we don't just implement
> > native_read_msr() as just
> >
On Mon, Sep 21, 2015 at 09:36:15AM -0700, Linus Torvalds wrote:
> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
> >
> > Linus, what's your preference?
>
> So quite frankly, is there any reason we don't just implement
> native_read_msr() as just
>
>unsigned long long native_read_msr(uns
On 21/09/2015 19:43, Andy Lutomirski wrote:
> And maybe the KVM user return notifier.
No, not really. If anything, the place in KVM where it makes a
difference is vmx_save_host_state, which is also only using
always-present MSRs. But don't care about KVM.
First clean it up, then we can add ba
* Linus Torvalds wrote:
> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
> >
> > Linus, what's your preference?
>
> So quite frankly, is there any reason we don't just implement
> native_read_msr() as just
>
>unsigned long long native_read_msr(unsigned int msr)
>{
> int err
On Mon, Sep 21, 2015 at 11:16 AM, Andy Lutomirski wrote:
>
> In the interest of sanity, I want to drop the "native_", too
Yes. I think the only reason it exists is to have that wrapper layer
for PV. And that argument just goes away if you just make the
non-inline helper function do all the PV log
On Mon, Sep 21, 2015 at 11:16:30AM -0700, Andy Lutomirski wrote:
> In the interest of sanity, I want to drop the "native_", too, since
> there appear to be few or no good use cases for native_read_msr as
> such. I'm tempted to add new functions read_msr and write_msr that
> forward to rdmsrl_safe
On Mon, Sep 21, 2015 at 9:36 AM, Linus Torvalds
wrote:
> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
>>
>> Linus, what's your preference?
>
> So quite frankly, is there any reason we don't just implement
> native_read_msr() as just
>
>unsigned long long native_read_msr(unsigned int ms
On Mon, Sep 21, 2015 at 9:49 AM, Arjan van de Ven wrote:
> On 9/21/2015 9:36 AM, Linus Torvalds wrote:
>>
>> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
>>>
>>>
>>> Linus, what's your preference?
>>
>>
>> So quite frankly, is there any reason we don't just implement
>> native_read_msr() a
On Mon, Sep 21, 2015 at 9:49 AM, Arjan van de Ven wrote:
>>
>> How many msr reads are so critical that the function call
>> overhead would matter?
>
> if anything qualifies it'd be switch_to() and friends.
Is there anything else than the FS/GS_BASE thing (possibly hidden
behind inlines etc that I
On 9/21/2015 9:36 AM, Linus Torvalds wrote:
On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
Linus, what's your preference?
So quite frankly, is there any reason we don't just implement
native_read_msr() as just
unsigned long long native_read_msr(unsigned int msr)
{
int er
On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
>
> Linus, what's your preference?
So quite frankly, is there any reason we don't just implement
native_read_msr() as just
unsigned long long native_read_msr(unsigned int msr)
{
int err;
unsigned long long val;
val = na
On 21/09/2015 10:46, Ingo Molnar wrote:
> Or we could extend exception table entry encoding to include a 'warning bit',
> to
> not bloat the kernel. If the exception handler code encounters such an
> exception
> it would generate a one-time warning for that entry, but otherwise not crash
> t
* Andy Lutomirski wrote:
> On Sep 20, 2015 5:15 PM, "Linus Torvalds"
> wrote:
> >
> > On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski wrote:
> > > This demotes an OOPS and likely panic due to a failed non-"safe" MSR
> > > access to a WARN_ON_ONCE and a return of zero (in the RDMSR case).
> >
On Sep 20, 2015 5:15 PM, "Linus Torvalds" wrote:
>
> On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski wrote:
> > This demotes an OOPS and likely panic due to a failed non-"safe" MSR
> > access to a WARN_ON_ONCE and a return of zero (in the RDMSR case).
> > We still write a pr_info entry unconditi
On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski wrote:
> This demotes an OOPS and likely panic due to a failed non-"safe" MSR
> access to a WARN_ON_ONCE and a return of zero (in the RDMSR case).
> We still write a pr_info entry unconditionally for debugging.
No, this is wrong.
If you really wan
This demotes an OOPS and likely panic due to a failed non-"safe" MSR
access to a WARN_ON_ONCE and a return of zero (in the RDMSR case).
We still write a pr_info entry unconditionally for debugging.
To be clear, this type of failure should *not* happen. This patch
exists to minimize the chance of
21 matches
Mail list logo