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 A69A1C433F5 for ; Thu, 5 May 2022 13:16:25 +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=O7A24ZdMqF5DJ/EG/rGU4J/KnJAtUb24rsIWUMvvUnw=; b=WukKyHCbTGL1bO M9cZNu46XdB3u47pM6KA3ddO4qSSv7xSS3afYy0YWZWIwCrXlSju/rIVhhJPRx8DbfSH9Qlu1sEiF bcw+jfFxUbl29atYfbxdkS4zb6+0uoKfLQ2Frc1QcW4OrO2fqgUUZbuuDmHBvrDqNCUL8JoZlrCJT +JsMLMTtgDHDU4D36CxzfMZ/t8SO2RjCIau6JF1vr8fthl/VgNBx2pBLxSdLb0CVODAVlkYu9XEID jYcWDflFBB36rdOK9/e3osQQ3hbMdx8wk1KpH/f6N5o2OmUwluvmNOLqRrS1EarGgHmSSzg+8Q6BO rGEIlTTEdWt9gZXJAyow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmbKE-00FzI8-HS; Thu, 05 May 2022 13:15:22 +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 1nmbKA-00FzHL-Dq for linux-arm-kernel@lists.infradead.org; Thu, 05 May 2022 13:15:19 +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 395E1106F; Thu, 5 May 2022 06:15:16 -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 89EEA3F885; Thu, 5 May 2022 06:15:14 -0700 (PDT) Date: Thu, 5 May 2022 14:15:11 +0100 From: Mark Rutland To: "Guilherme G. Piccoli" Cc: "Michael Kelley (LINUX)" , Marc Zyngier , Catalin Marinas , will Deacon , 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> <3bee47db-f771-b502-82a3-d6fac388aa89@igalia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3bee47db-f771-b502-82a3-d6fac388aa89@igalia.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220505_061518_555882_76C523F2 X-CRM114-Status: GOOD ( 28.57 ) 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 10:05:18AM -0300, Guilherme G. Piccoli wrote: > On 05/05/2022 09:53, Mark Rutland wrote: > > [...] > > 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. > > Hi Mark, my plan would be doing that for Hyper-V - kind of the same > code, almost. For example, in hv_crash_handler() there is a stimer > clean-up and the vmbus unload - my understanding is that this same code > would need to run in arm64. Michael Kelley is CCed, he was discussing > with me in the panic notifiers thread and may elaborate more on the needs. The key problem here is that there's no justification as to why this cannot be done in a panic notifier (or a regular reboot notifer for the plain shutdown or kexec case). I undertstand that x86 does one thing, and what Marc and I have said is that fact alone doesn't justify doing the same. We need to know: a) What specifically you want to do on arm64 b) Why you think this cannot be done using the existing mechanisms (e.g. notifiers). Without a strong justification, we wouldn't add such hooks to arm64. Could you start by trying to use the notifiers, and if you encounter a problem, *then* we consider an alternative? That should mean we have a concrete reason. Thanks, Mark. > But also (not related with my specific plan), I've seen KVM quiesce code > on x86 as well [see kvm_crash_shutdown() on arch/x86] , I'm not sure if > this is necessary for arm64 or if this already executing in some > abstracted form, I didn't dig deep - probably Vitaly is aware of that, > hence I've CCed him here. > > Cheers, > > > Guilherme _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel