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

2016-03-15 Thread Ingo Molnar
* Ingo Molnar wrote: > * Andy Lutomirski wrote: > > > On Mon, Mar 14, 2016 at 11:40 AM, Linus Torvalds > > wrote: > > > On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski > > > wrote: > > >> > > >>

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

2016-03-15 Thread Ingo Molnar
* Andy Lutomirski wrote: > On Mon, Mar 14, 2016 at 11:40 AM, Linus Torvalds > wrote: > > On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski > > wrote: > >> > >> The code in my queue is, literally: > >> > >> bool

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

2016-03-15 Thread Ingo Molnar
* Linus Torvalds wrote: > On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski wrote: > > > > So yes, let's please warn. I'm okay with removing the panic_on_oops > > thing though. (But if anyone suggests that we should stop OOPSing on > > bad

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

2016-03-14 Thread Peter Zijlstra
On Mon, Mar 14, 2016 at 11:10:16AM -0700, Andy Lutomirski wrote: > A couple of the wrmsr users actually care about performance. These > are the ones involved in context switching and, to a lesser extent, in > switching in and out of guest mode. Right, this very much includes a number of perf

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

2016-03-14 Thread Andy Lutomirski
On Mon, Mar 14, 2016 at 11:40 AM, Linus Torvalds wrote: > On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski wrote: >> >> The code in my queue is, literally: >> >> bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup, >>

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

2016-03-14 Thread Linus Torvalds
On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski wrote: > > The code in my queue is, literally: > > bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup, > struct pt_regs *regs, int trapnr) > { > WARN_ONCE(1, "unchecked MSR access

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

2016-03-14 Thread Andy Lutomirski
On Mon, Mar 14, 2016 at 11:15 AM, Linus Torvalds wrote: > On Mon, Mar 14, 2016 at 11:10 AM, Andy Lutomirski wrote: >> >> A couple of the wrmsr users actually care about performance. These >> are the ones involved in context switching and, to a

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

2016-03-14 Thread Andy Lutomirski
On Mon, Mar 14, 2016 at 11:04 AM, Linus Torvalds wrote: > On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski wrote: >> >> So yes, let's please warn. I'm okay with removing the panic_on_oops >> thing though. (But if anyone suggests that we

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

2016-03-14 Thread Linus Torvalds
On Mon, Mar 14, 2016 at 11:10 AM, Andy Lutomirski wrote: > > A couple of the wrmsr users actually care about performance. These > are the ones involved in context switching and, to a lesser extent, in > switching in and out of guest mode. .. ok, see the crossed emails. I'd

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

2016-03-14 Thread Linus Torvalds
On Mon, Mar 14, 2016 at 11:04 AM, Linus Torvalds wrote: > > None of this insane complicated crap that buys us exactly *nothing*, > and depends on fancy new exception handling support etc etc. Actually, the one _new_ thing we could do is to instead of removing the

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

2016-03-14 Thread Linus Torvalds
On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski wrote: > > So yes, let's please warn. I'm okay with removing the panic_on_oops > thing though. (But if anyone suggests that we should stop OOPSing on > bad kernel page faults, I *will* fight back.) Bad kernel page faults

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

2016-03-14 Thread Andy Lutomirski
On Mon, Mar 14, 2016 at 10:11 AM, Linus Torvalds wrote: > > On Mar 14, 2016 10:05 AM, "Andy Lutomirski" wrote: >> >> We could probably remove that check and let custom fixups run early. >> I don't see any compelling reason to keep them

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

2016-03-14 Thread Linus Torvalds
On Mar 14, 2016 10:05 AM, "Andy Lutomirski" wrote: > > We could probably remove that check and let custom fixups run early. > I don't see any compelling reason to keep them disabled. That should > probably be a separate change, though. Or we could just use the existing

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

2016-03-14 Thread Andy Lutomirski
On Mon, Mar 14, 2016 at 5:02 AM, Borislav Petkov wrote: > On Sat, Mar 12, 2016 at 10:08:49AM -0800, Andy Lutomirski wrote: >> This demotes an OOPS and likely panic due to a failed non-"safe" MSR >> access to a WARN_ONCE and, for RDMSR, a return value of zero. If >> panic_on_oops

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

2016-03-14 Thread Borislav Petkov
On Sat, Mar 12, 2016 at 10:08:49AM -0800, Andy Lutomirski wrote: > This demotes an OOPS and likely panic due to a failed non-"safe" MSR > access to a WARN_ONCE and, for RDMSR, a return value of zero. If > panic_on_oops is set, then failed unsafe MSR accesses will still > oops and panic. > > To

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

2016-03-12 Thread Andy Lutomirski
This demotes an OOPS and likely panic due to a failed non-"safe" MSR access to a WARN_ONCE and, for RDMSR, a return value of zero. If panic_on_oops is set, then failed unsafe MSR accesses will still oops and panic. To be clear, this type of failure should *not* happen. This patch exists to