Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932172AbcCNSLI (ORCPT ); Mon, 14 Mar 2016 14:11:08 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:34830 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755296AbcCNSLA (ORCPT ); Mon, 14 Mar 2016 14:11:00 -0400 MIME-Version: 1.0 In-Reply-To: References: <20160314120202.GD15800@pd.tnic> Date: Mon, 14 Mar 2016 11:10:59 -0700 X-Google-Sender-Auth: _TS7iQdwOI5Y1jVyBj6ZOKxLleY Message-ID: Subject: Re: [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops From: Linus Torvalds To: Andy Lutomirski Cc: Paolo Bonzini , xen-devel , Arjan van de Ven , Borislav Petkov , X86 ML , Andrew Morton , KVM list , Andy Lutomirski , "linux-kernel@vger.kernel.org" , Peter Zijlstra Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1044 Lines: 24 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 old crappy rdmsr()/wrmsr() implementation entirely, we'll just rename it to "rd/wrmsr_unsafe()", and not have any exception table stuff for that at all (so now you *will* get an oops and panic if you use that). The only reason to do that is for performance-critical MSR's that really don't want any overhead. Sure, they could just be changed to use "wrmsr_safe()", but for things like the APIC accesses, or update_debugctlmsr() (that is supposed to check for processor version) that can be truly critical, an explicitly _unsafe_ version may be the right thing to do. The fact is, the problem with rd/wrmsr is that we just did the defaults the wrong way around. Making the simple and obvious version be unsafe is just wrong. Linus