Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp7777200rwl; Tue, 10 Jan 2023 05:23:57 -0800 (PST) X-Google-Smtp-Source: AMrXdXtdaXtA6+enOqyrSxL5pQPAckkCgvWVSVHnkslx9v94C0lhIcH3b5inB/imHe2NCiYgzYzx X-Received: by 2002:a05:6402:6c9:b0:46c:2c94:d30b with SMTP id n9-20020a05640206c900b0046c2c94d30bmr75019028edy.33.1673357037698; Tue, 10 Jan 2023 05:23:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673357037; cv=none; d=google.com; s=arc-20160816; b=peIE4sGPWoqGL/3x6o87SPqBbiOaYWNvOAD749CeFmkPED99G5YjN1KTsWAJ03kEF8 tnvI3Xnz/JHbJ+FVNCOOw8lMFj0Ugr/DNp8TVt3sU1CUziOu4t83ISDm9zCP4DqM/FCn jYP41S+2cAjWnxDVdpxMVYGQZ7WXIJdNbxHk5Jlu7yKiJZ0j58gpwASKQV2UN+IHOgEv baTCRRH8LH1VGYZkL+AZjbHwr2Jk1gognQc+dFxZj4dy4s2p/jApluZDF5Z3S78zrGUp DIoX2wHjMQ2z5yhlt69sxNDFo4Td+MGxt/cUuUApAT5rTvdJnq3iTv7KXC9r1nhanjmN NVlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=e3aZbrX9jsLB8Y3WAfNCVrD8tFak09w/8UN5B8tb074=; b=sfxGAY9E/NXRRDFR+I6Ej0ExPvC3Cz0GFsCgUvIKJj2FpY9aOBP0UX1Koh/gfW4Iu/ cgNdsw+LaAWbT8IUrx/ab7JKHCmEoqdC5wEdjk2zaEuMBpaYfT8vB9GMdYCDRUO9/8d3 7Rwu0MvolX0qpkqqQdc3CwYrc5skYs07AIu1So/1wlPkv0E+XH7K9cTvq3WQx7+kLQA0 J1i6caV3BbagvvrDF7QcOWeyqin0qgZGbEh4btUnLetkg3jX9IRcrF2FK23UDEaXVXHN EnVGr3vx99+U8jEKKvHlbcjxrhh2eBte/drso/ujA2TVlzA7YGMYkWWKboWScdyCSt07 S/WQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=n8stqYgb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o14-20020aa7dd4e000000b0048ea26ce021si10832767edw.68.2023.01.10.05.23.44; Tue, 10 Jan 2023 05:23:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=n8stqYgb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238525AbjAJM5O (ORCPT + 53 others); Tue, 10 Jan 2023 07:57:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238467AbjAJM5M (ORCPT ); Tue, 10 Jan 2023 07:57:12 -0500 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3AB191DDE8 for ; Tue, 10 Jan 2023 04:57:11 -0800 (PST) Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (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 A93A51EC04AD; Tue, 10 Jan 2023 13:57:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1673355429; 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=e3aZbrX9jsLB8Y3WAfNCVrD8tFak09w/8UN5B8tb074=; b=n8stqYgbfzuFA/wxS1p8sxfshrdVy3fNeEcz5YAGqhIj5RZ6DGPqYYXqA4hvwKuXAn+Q1J HKp7zcHn854pj0u/3jsMIhMAF64DiED87duiVkYKLHpZ0cjEK3AEpNiX9IDyL5x6BkXuEq I+whqeZWwW1MJaD4BvXd6v3zONT4KSY= Date: Tue, 10 Jan 2023 13:57:05 +0100 From: Borislav Petkov To: Zeng Heng Cc: Ingo Molnar , michael.roth@amd.com, hpa@zytor.com, tglx@linutronix.de, sathyanarayanan.kuppuswamy@linux.intel.com, kirill.shutemov@linux.intel.com, jroedel@suse.de, keescook@chromium.org, mingo@redhat.com, dave.hansen@linux.intel.com, brijesh.singh@amd.com, linux-kernel@vger.kernel.org, x86@kernel.org, liwei391@huawei.com Subject: Re: [PATCH -v2] x86/boot/compressed: Register dummy NMI handler in EFI boot loader, to avoid kdump crashes Message-ID: References: <20230110102745.2514694-1-zengheng4@huawei.com> <684a2472-f388-b2e1-4a7a-7bc9a07650b4@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <684a2472-f388-b2e1-4a7a-7bc9a07650b4@huawei.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 10, 2023 at 08:32:07PM +0800, Zeng Heng wrote: > mce is registered on NMI handler by inject_init(). That's a handler for the NMI raised by raise_mce(). That's for the injection case, which is simulated. If you're fixing the injection case, then surely not with a bogus boot NMI handler. > Yes, exactly. The following procedure is like: > > panic() -> relocate_kernel() -> identity_mapped() -> x86 purgatory image -> > EFI loader -> secondary kernel I'm doubtful now as you're injecting errors so you're not really in #MC context but in this contrived context which is actually an NMI one. So we need to think about how to fix this case. Certainly not with an empty NMI handler... Regardless, we should do diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c index 7832a69d170e..57fe376ed049 100644 --- a/arch/x86/kernel/cpu/mce/core.c +++ b/arch/x86/kernel/cpu/mce/core.c @@ -286,6 +286,8 @@ static noinstr void mce_panic(const char *msg, struct mce *final, char *exp) if (!fake_panic) { if (panic_timeout == 0) panic_timeout = mca_cfg.panic_timeout; + + mce_wrmsrl(MSR_IA32_MCG_STATUS, 0); panic(msg); } else pr_emerg(HW_ERR "Fake kernel panic: %s\n", msg); so that we not run kexec in #MC context. Hmmm. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette