From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C8B6C55ABD for ; Tue, 10 Nov 2020 06:32:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0E6D220731 for ; Tue, 10 Nov 2020 06:32:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alien8.de header.i=@alien8.de header.b="NF7Hb8OO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731545AbgKJGcB (ORCPT ); Tue, 10 Nov 2020 01:32:01 -0500 Received: from mail.skyhub.de ([5.9.137.197]:33612 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730520AbgKJGcA (ORCPT ); Tue, 10 Nov 2020 01:32:00 -0500 Received: from nazgul.tnic (unknown [78.130.214.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 1884B1EC036E; Tue, 10 Nov 2020 07:31:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1604989919; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=DbPzFD8ocADSeV0o8zIHgtkE0g19VhGWZQrcUWattEg=; b=NF7Hb8OOJrdOKerg7Qh7vYnZk0Yhj5SSyahwpktISeLTD33gEccKEuaoh26lnk6cBRcDWl qFqM7Zy8363qpSYHk64rOlcre49J0n4nGdKIxH4Qk82DQv4s9izB8+WuigLDA1d2W258gM ibxzwfEm+hPuO5+euAZ335R3wucO/dQ= Date: Tue, 10 Nov 2020 07:31:51 +0100 From: Borislav Petkov To: "Luck, Tony" Cc: Jim Mattson , Qian Cai , "linux-kernel@vger.kernel.org" , "linux-tip-commits@vger.kernel.org" , x86 , Paolo Bonzini , "kvm@vger.kernel.org" Subject: Re: [PATCH] x86/mce: Check for hypervisor before enabling additional error logging Message-ID: <20201110063151.GB7290@nazgul.tnic> References: <20201030190807.GA13884@agluck-desk2.amr.corp.intel.com> <160431588828.397.16468104725047768957.tip-bot2@tip-bot2> <3f863634cd75824907e8ccf8164548c2ef036f20.camel@redhat.com> <20201109232402.GA25492@agluck-desk2.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201109232402.GA25492@agluck-desk2.amr.corp.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 09, 2020 at 03:24:02PM -0800, Luck, Tony wrote: > Booting as a guest under KVM results in error messages about > unchecked MSR access: > > [ 6.814328][ T0] unchecked MSR access error: RDMSR from 0x17f at rIP: 0xffffffff84483f16 (mce_intel_feature_init+0x156/0x270) > > because KVM doesn't provide emulation for random model specific registers. > > Check for X86_FEATURE_HYPERVISOR and skip trying to enable the mode (a > guest shouldn't be concerned with corrected errors anyway). > > Reported-by: Qian Cai > Fixes: 68299a42f842 ("x86/mce: Enable additional error logging on certain Intel CPUs") > Signed-off-by: Tony Luck > --- > arch/x86/kernel/cpu/mce/intel.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/kernel/cpu/mce/intel.c b/arch/x86/kernel/cpu/mce/intel.c > index b47883e364b4..7f7d863400b7 100644 > --- a/arch/x86/kernel/cpu/mce/intel.c > +++ b/arch/x86/kernel/cpu/mce/intel.c > @@ -517,6 +517,9 @@ static void intel_imc_init(struct cpuinfo_x86 *c) > { > u64 error_control; > > + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) > + return; > + Frankly, I'm tired of wagging the dog because the tail can't. If qemu/kvm can't emulate a CPU model fully then it should ignore those unknown MSR accesses by default, i.e., that "ignore_msrs" functionality should be on by default I'd say... We certainly can't be sprinkling this check everytime the kernel tries to do something as basic as read an MSR. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette