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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2ECC4C433FE for ; Thu, 5 May 2022 12:54:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3Q4HW78OXfGU8oaNCL5k0Egqel2JuD0a+LBUI1xKNec=; b=chGbU8JLyvx9hR UBhWbvnaMCNS6Sqo9OaYx7lS5tGyLtqTmv9sONVRbX+Qwulhn2qxfzNybCXW29WqpUCtwEBbQeU/0 BkQXGPf/xowj0bB8ATnGjz6tvv1oSyDKieErALWhbUcdtVmBzIL5B5wKVjToVtRHfc3ddyYpdmvDo 4yHOdMlKs/AWr1PaPezz6bNsJ/M9XLApjttMUDtmLWtwfayKoH+xb2YrIXDYCxD57cP5j3k+0wUqB cGbiwRy5taiREnKu+wZdU9pCh3vl2hF1kOh/PcVSIytMAREpc5B3d2136wtpwUymVL38m3P1usOG3 E/TFlrRSJK/jL9ZbYzBQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmaz8-00FtJm-0K; Thu, 05 May 2022 12:53:34 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmaz4-00FtHY-EJ for linux-arm-kernel@lists.infradead.org; Thu, 05 May 2022 12:53:32 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A2D8F106F; Thu, 5 May 2022 05:53:26 -0700 (PDT) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.29.132]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 027A53F885; Thu, 5 May 2022 05:53:24 -0700 (PDT) Date: Thu, 5 May 2022 13:53:22 +0100 From: Mark Rutland To: "Guilherme G. Piccoli" Cc: Marc Zyngier , Catalin Marinas , will Deacon , "Michael Kelley (LINUX)" , Vitaly Kuznetsov , Russell King , Ard Biesheuvel , broonie@kernel.org, "linux-arm-kernel@lists.infradead.org" , linux-kernel , "linux-hyperv@vger.kernel.org" Subject: Re: Should arm64 have a custom crash shutdown handler? Message-ID: References: <427a8277-49f0-4317-d6c3-4a15d7070e55@igalia.com> <874k24igjf.wl-maz@kernel.org> <92645c41-96fd-2755-552f-133675721a24@igalia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <92645c41-96fd-2755-552f-133675721a24@igalia.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220505_055330_572120_BD9F79E2 X-CRM114-Status: GOOD ( 28.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, May 05, 2022 at 09:44:25AM -0300, Guilherme G. Piccoli wrote: > On 05/05/2022 04:29, Marc Zyngier wrote: > > [...] > > Not having any 'machine_ops' indirection was a conscious decision on > > arm64, if only to avoid the nightmare that 32bit was at a time with > > every single platform doing their own stuff. Introducing them would > > not be an improvement, but simply the admission that hypervisors are > > simply too broken for words. And I don't buy the "but x86 has it!" > > argument. x86 is a nightmare of PV mess that we can happily ignore, > > because we don't do PV for core operations at all. > > > > If something has to be done to quiesce the system, it probably is > > related to the system topology, and must be linked to it. We already > > have these requirements in order to correctly stop ongoing DMA, shut > > down IOMMUs, and other similar stuff. What other requirements does > > your favourite hypervisor have? > > > > Thanks Marc and Mark for the details. I agree with most part of it, and > in fact panic notifiers was the trigger for this discussion (and they > are in fact used for this purpose to some extent in Hyper-V). > > The idea of having this custom handler from kexec comes from Hyper-V > discussion - I feel it's better to show the code, so please take a look > at functions: hv_machine_crash_shutdown() > [arch/x86/kernel/cpu/mshyperv.c] and the one called from there, > hv_crash_handler() [drivers/hv/vmbus_drv.c]. > > These routines perform last minute clean-ups, right before kdump/kexec > happens, but *after* the panic notifiers. It seems there is no way to > accomplish that without architecture involvement or core kexec code > pollution heh Looking at those, the cleanup work is all arch-specific. What exactly would we need to do on arm64, and why does it need to happen at that point specifically? On arm64 we don't expect as much paravirtualization as on x86, so it's not clear to me whether we need anything at all. > Anyway, the idea here was to gather a feedback on how "receptive" arm64 > community would be to allow such customization, appreciated your feedback =) ... and are you trying to do this for Hyper-V or just using that as an example? I think we're not going to be very receptive without a more concrete example of what you want. What exactly do *you* need, and *why*? Is that for Hyper-V or another hypervisor? Thanks Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel