From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D1F0606A31B for ; Tue, 20 Oct 2026 01:40:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=NMd8KqkJ; dkim=pass (2048-bit key, unprotected) header.d=igalia.com header.i=@igalia.com header.a=rsa-sha256 header.s=20170329 header.b=gz3Y0cld DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Y/v52Nt7wua3/Hqh2/eSRWr2zKr9agsfw3+QaI3Wh7o=; b=NMd8KqkJGn9bLKV6gkk5SVaqFA O+X03vmG4/1zTplYZCwc90MBzp9iv9bYYskflsbgGAVn8962kspHDnRBZIrMjn/X2hEWzgOnxXuDJ 5gD5LchMvFpXaZgMslUnHSbEist05UCiJMYZ1mpG8uEdCky7uNvTuUQX6JLPZhUeLuKvFIlA8iS/b AyTlTpfoVWaUXTuqABGssPrL3KvnoDa5UqiJTtnUw/ABDitUiOd7cB1SRlZNbsrxcJ0nLvQCwbfXY 13N6A/fnoWFlRLPNudOr+NOB5+sTgrYQ4erC44sRL5Gi83Ud+Wz7jvo3WKyohZ06iaRHDKI2fPsx7 a2J121sQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xIyqI-00000008dOO-45D6; Tue, 20 Oct 2026 01:40:42 +0000 Received: from fanzine2.igalia.com ([213.97.179.56]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xIyqG-00000008dNi-2YLu for kexec@lists.infradead.org; Tue, 20 Oct 2026 01:40:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:From:Cc:To:Subject: MIME-Version:Date:Message-ID:From:Reply-To; bh=Y/v52Nt7wua3/Hqh2/eSRWr2zKr9agsfw3+QaI3Wh7o=; b=gz3Y0cldVWyCo401TUdb94v8wa YoSB0h8baJhpIXaCi9PlSKT+G0Ap571CVXBDOFWQnrW1IXDQY2olHhBiDqAs8u0baPqzVYPzsAcDc FzGtkjvYOjmHF6SUB8pFSNuwMObtBQOQd7Flb8gBocyw1DyA5fjgKE0qBfhyclWFTfwxTxjHTKv5p zXjPNqwA+XUlZCu50sJcr3fyf0qN9IjtiBlZ8hU69wnf2hTYoaVQn9aQe4fd8X2miull6Un5xUhQq QO9/s4noupNuak9u8vOqWLS3ze7ZAmWHZZCzpL9QYM5ooDl36WVwy2Ovx/qhD/4YMPnyiu6x62FFF 2EcCKf8g==; Received: from [177.189.74.83] (helo=[192.168.15.93]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1xIypa-0044FE-6B; Tue, 20 Oct 2026 03:39:58 +0200 Message-ID: <83dffabb-c702-eec9-a992-ba5b9530a8cc@igalia.com> Date: Mon, 19 Oct 2026 22:39:49 -0300 X-Archived-By: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v1 4/4] x86/vmware: Run panic diagnostics before kdump by default Content-Language: en-US To: Stephen Brennan , Petr Mladek , Zack Rusin Cc: Borislav Petkov , Ajay Kaher , Alexey Makhalov , x86@kernel.org, Joel Granados , Baoquan He , Thomas Gleixner , Ingo Molnar , Dave Hansen , "H . Peter Anvin" , virtualization@lists.linux.dev, bcm-kernel-feedback-list@broadcom.com, linux-kernel@vger.kernel.org, John Ogness , Steven Rostedt , Sergey Senozhatsky , Kees Cook , Andrew Morton , Mike Rapoport , Pasha Tatashin , Pratyush Yadav , Dave Young , Jonathan Corbet , Bo Gan , Brennan Lamoreaux , kexec@lists.infradead.org, linux-doc@vger.kernel.org References: <7487011dfb95aadda9515b22a5852680df1982c5.1788414671.git.zack.rusin@broadcom.com> <87v77p9t4h.fsf@oracle.com> From: "Guilherme G. Piccoli" In-Reply-To: <87v77p9t4h.fsf@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20261019_184040_998141_9B14112E X-CRM114-Status: GOOD ( 26.72 ) X-Spam-Score: -4.5 (----) X-BeenThere: kexec@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "kexec" X-Spam-Status: No, score=-10.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 On 28/09/2026 14:35, Stephen Brennan wrote: > [...] > Hi Guilherme, thanks for CCing me! You're right, I'm interested too :D > Your email arrived on the first day of my vacation, so I'm sorry for the > delayed response. Hi Stephen! Nice talking to you =) No worries at all, this is also conference season heh > [...] > I do think we're going to have trouble articulating exactly what are the > criteria for a "pre_kdump" notifier vs a "panic" notifier? Anyone > submitting a patch believes their notifier is important, so of course > they believe it belongs on the pre_kdump list! How will we draw the line > in the future? > > - Is it safety? As in "the notifier doesn't take any locks"? I feel > this should be part of the criteria. (Though I have never been > successful in predicting what code would cause a kdump/panic failure) > - Is it urgency? As in "without this, the expected behavior of the > system during a panic will not occur". > - Is it the fact that the notifier is communicating with the hypervisor? > > From my perspective: informing the hypervisor of a panic is both safe > and urgent. If the hypervisor is configured to immediately halt and do > its own panic handling, great. > This is a very good point. What is the criteria? I honestly don't know...I think hypervisor-related things, that are safe (as you put) makes sense. Anything that might also make kdump work more reliably, and is safe as well...but everyone will judge their notifier important, in the end heh > Providing the last 4KB of logs seems less safe and less urgent (though > obviously still immensely helpful). The kernel provides a huge variety > of consoles through which the hypervisor could have already received > these logs. If the system is configured not to use them... it seems the > tradeoff to not be debuggable has already been made :P > To me, that logic belongs in a standard panic notifier. > > Plenty of people will likely disagree with me on that, but that's why it > would be helpful to have clarity on what separates pre_kdump from > standard panic notifiers. > But at the same time ... there's something else, the "self-contained" nature of hypervisor-related notifiers. This one is restricted for vmware only, so personally, I think it's not a super biggie to run it early. It is, in the end, a decision of vmware stakeholders. If that would be an arch notifier, something that all arm64 users would necessarily run, for example, I'd be way more skeptic on putting it early. Anyway, not sure if I helped or if I contributed nothing to the criteria discussion heheh But I hope to see this discussion happening, maybe should also gets documented as part of future Zach's patch iteration as well. Cheers, Guilherme