Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

* 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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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%

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

* 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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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.

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

* 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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

* 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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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 >

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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)

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

* 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 > > >

[Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

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.