Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp3696147pxy; Tue, 4 May 2021 08:01:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwrZV91yHM22z424BwWwoYV0M++itxbYTCIJ2y1e+ndj/LntVUHHj/BB0MFmBZK6DHDxG/a X-Received: by 2002:a05:6402:40d2:: with SMTP id z18mr11015991edb.81.1620140487907; Tue, 04 May 2021 08:01:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620140487; cv=none; d=google.com; s=arc-20160816; b=QrMDCeN2HT42uteOoqbCtMQlMVSAyTzK1AuQ+zVvQkMuKYdlmcIYvfVkYrCRVEfNl7 UOa0h8ltLaPqJ+RTlBn9tOXOMDiDlSAD0UVe7m6GZbdgZTfVHYG+5xTQWTHhvkwSxUht ilfun6F64OiadZC2/7k2K8WLeHZfDk/WgZJqX8xjaRfZbaNinZIkh30d5DupogoXCOHq gIBKVKFYmTKCibaofJcIhT0e8rTpFbOPBV0oIgJInRssCJ+KeCu1ixgr5ZppnLDQq2BU SSWi4mZTWFMmz/y3qfqT2Ngv0HITQgZaaAJaJU6Khjhcx2gMTz3XivKsR8TnNSUTj4tc UPAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=BR3v2+p903dGyaTnMIq3ixCFpMkgOvkdYdpyOkK9gWA=; b=sO+QEOEiJmkyB6LQlzM8BKhP8CbTDCqJidLuN3jMqNquP/KG0TLQxDy2LALA6hyVk1 lmRcuAH29yzTOeFxKcb3sHu+4oXn45neuxOPAvY+JUeweph817QXVXoVCiYCzLsk6yZf JPtfDfVt/RwCioKGoeXgILKaupWxfJ5oXACBKxoeOaIFqfrjArVbk0meOTKdTlV71yUI TDb6RYSy1fHWmvK+HSue5DIworhLUduyagh40l3R9TuC7BPG0wTF/jLiUtpsW+/raAbE eFZbQjxZJf5VP2KPLtnWdmYVLxX2gT7jNXdCbL11h2bnGjM+o6n62A7X+tckJIuphfzh Rtrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=YGpYnDub; dkim=neutral (no key) header.i=@linutronix.de header.b=S1B4Qb8V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w6si11877396edq.494.2021.05.04.08.01.04; Tue, 04 May 2021 08:01:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=YGpYnDub; dkim=neutral (no key) header.i=@linutronix.de header.b=S1B4Qb8V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230318AbhEDMom (ORCPT + 99 others); Tue, 4 May 2021 08:44:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230256AbhEDMol (ORCPT ); Tue, 4 May 2021 08:44:41 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B684C061574 for ; Tue, 4 May 2021 05:43:47 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1620132225; 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: in-reply-to:in-reply-to:references:references; bh=BR3v2+p903dGyaTnMIq3ixCFpMkgOvkdYdpyOkK9gWA=; b=YGpYnDubeYG4hztg6Ab9SMmTMvPkQnJ+39Xc91UX1nvVlQRdSkpj6YLRaHf+ZSA9+AU72G gKfXtHbWoUDv5aB5S2E7vvewUGiz/F+h9a2ZEXre+KsKAhtadRFKCup5O/hzvksW0HRjGH rh3mPaT4kOyaX2ciYp1whIQXkshvinHoI+pvfVz+HSXcxPsa/PPOI/LoQsOj2+cgBZ/J8r 8GUBpgEBftxyBbTrex3kgHJ9LgZmYy5HYw33rj14Ert4J4Gg4cS4sKPtswOMVhWJs9YhwW J1xt2Lmdkzm2tUv97S1z2u9ggh7ll2hOWx8DVllI8mY0jrTIHIdeR3ROpQrg4Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1620132225; 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: in-reply-to:in-reply-to:references:references; bh=BR3v2+p903dGyaTnMIq3ixCFpMkgOvkdYdpyOkK9gWA=; b=S1B4Qb8VmFFB8YO1vKikYM+tXoOcZz1BocPDW/Hx7/m2cG9qidy0SVZkSAV5eNpCQOJ2Oa WX+qTtFezIHDrNBQ== To: Lai Jiangshan , linux-kernel@vger.kernel.org Cc: Lai Jiangshan , Paolo Bonzini , Sean Christopherson , Steven Rostedt , Andi Kleen , Andy Lutomirski , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Josh Poimboeuf , Uros Bizjak , Maxim Levitsky , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Alexandre Chartre , Juergen Gross , Joerg Roedel , Jian Cai Subject: Re: [PATCH 2/4] x86/entry: Use asm_noist_exc_nmi() for NMI in early booting stage In-Reply-To: <875yzzjxth.ffs@nanos.tec.linutronix.de> References: <20210426230949.3561-1-jiangshanlai@gmail.com> <20210426230949.3561-3-jiangshanlai@gmail.com> <87bl9rk23k.ffs@nanos.tec.linutronix.de> <878s4vk1l9.ffs@nanos.tec.linutronix.de> <875yzzjxth.ffs@nanos.tec.linutronix.de> Date: Tue, 04 May 2021 14:43:44 +0200 Message-ID: <87wnseis8v.ffs@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 03 2021 at 23:45, Thomas Gleixner wrote: > The problem was introduced in 4.14 with b70543a0b2b6 ("x86/idt: Move > regular trap init to tables"). > > Before that trap_init() installed an IST gate right away, but looking > deeper this was broken forever because there is a hen and egg problem. > > ISTs only work after TSS is initialized and the ordering here is: > > trap_init() > init_idt() > cpu_init() > init_tss() > > So the original code had a race window between init_idt() and > init_tss(). Any IST using exception in that window goes south because > TSS is not initialized. > > b70543a0b2b6 traded the above with that NMI issue. All other > exceptions are fine... > > I'll think about it tomorrow some more... It does not really matter which way around we do it. Even if we do that noist dance then still any NMI hitting _before_ init_idt() is going to lala land. So having this tiny step in between is more or less cosmetic. And just for completness sake, I don't see a reason why we have to set up the idt gates _before_ the TSS muck, i.e. before cpu_init(). The only thing cpu_init() needs working which is not installed in the early_idt is #GP because some cpu init code uses rd/wrmsrl_safe(). But that's pretty much all of it. So this wants a proper cleanup and not some paper over it with an extra step and I don't see a reason why any of this should be backported simply because it does not matter at all whether the early idt which only populates a few essential gates is active for a bit longer. So what we need is a solution for that KVM wreckage but that can be stand alone. Thanks, tglx