Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751404AbcDBOCF (ORCPT ); Sat, 2 Apr 2016 10:02:05 -0400 Received: from mail.kernel.org ([198.145.29.136]:59006 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750767AbcDBOCC (ORCPT ); Sat, 2 Apr 2016 10:02:02 -0400 From: Andy Lutomirski To: X86 ML Cc: Paolo Bonzini , Peter Zijlstra , KVM list , Arjan van de Ven , xen-devel , linux-kernel@vger.kernel.org, Linus Torvalds , Andrew Morton , Borislav Petkov , Andy Lutomirski Subject: [PATCH v5 0/9] Improve non-"safe" MSR access failure handling Date: Sat, 2 Apr 2016 07:01:31 -0700 Message-Id: X-Mailer: git-send-email 2.5.5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3291 Lines: 81 There are two parts here: ***** FIRST PART: EARLY EXCEPTIONS ***** The first few patches move some early panic code into C, add pt_regs to early exception handling, and make fancy exception handlers work early. ***** SECOND PART: MSRs ***** Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently turns all rdmsr and wrmsr operations into the safe variants without any checks that the operations actually succeed. With CONFIG_PARAVIRT=n, unchecked MSR failures OOPS and probably cause boot to fail if they happen before init starts. Neither behavior is very good, and it's particularly unfortunate that the behavior changes depending on CONFIG_PARAVIRT. In particular, KVM guests might be unwittingly depending on the PARAVIRT=y behavior because CONFIG_KVM_GUEST currently depends on CONFIG_PARAVIRT, and, because accesses in that case are completely unchecked, we wouldn't even see a warning. This series changes the native behavior, regardless of CONFIG_PARAVIRT. A non-"safe" MSR failure will give an informative warning once and will be fixed up -- native_read_msr will return zero, and both reads and writes will continue where they left off. If panic_on_oops is set, they will still OOPS and panic. By using the shiny new custom exception handler infrastructure, there should be no overhead on the success paths. I didn't change the behavior on Xen, but, with this series applied, it would be straightforward for the Xen maintainers to make the corresponding change -- knowledge of whether the access is "safe" is now propagated into the pvops. Doing this is probably a prerequisite to sanely decoupling CONFIG_KVM_GUEST and CONFIG_PARAVIRT, which would probably make Arjan and the rest of the Clear Containers people happy :) There's also room to reduce the code size of the "safe" variants using custom exception handlers in the future. Changes from v4: - Fix a missing \n (Joe Perches) - No more panic_on_oops - Works early Changes from v3: - WARN_ONCE instead of WARN (Ingo) - In the warning text, s/unsafe/unchecked/ (Ingo, sort of) Changes from earlier versions: lots of changes! Andy Lutomirski (9): x86/head: Pass a real pt_regs and trapnr to early_fixup_exception x86/head: Move the early NMI fixup into C x86/head: Move early exception panic code into early_fixup_exception x86/traps: Enable all exception handler callbacks early x86/paravirt: Add _safe to the read_msr and write_msr PV hooks x86/msr: Carry on after a non-"safe" MSR access fails x86/paravirt: Add paravirt_{read,write}_msr x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y x86/msr: Set the return value to zero when native_rdmsr_safe fails arch/x86/include/asm/msr.h | 20 ++++-- arch/x86/include/asm/paravirt.h | 45 +++++++------ arch/x86/include/asm/paravirt_types.h | 14 ++-- arch/x86/include/asm/uaccess.h | 2 +- arch/x86/kernel/head_32.S | 116 ++++++++++++++-------------------- arch/x86/kernel/head_64.S | 95 ++++++++-------------------- arch/x86/kernel/paravirt.c | 6 +- arch/x86/mm/extable.c | 64 +++++++++++++++---- arch/x86/xen/enlighten.c | 27 +++++++- 9 files changed, 208 insertions(+), 181 deletions(-) -- 2.5.5