Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4734905iob; Sun, 8 May 2022 23:41:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzCNOvWD8H4ON7WlPDjnDyeIsYEKDAwK6t07MqRbJljHFAV2h78wbO+PxT4LM8Fuhh2JnUg X-Received: by 2002:a17:902:ec83:b0:15e:b5d2:a81b with SMTP id x3-20020a170902ec8300b0015eb5d2a81bmr14807791plg.64.1652078493469; Sun, 08 May 2022 23:41:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652078493; cv=none; d=google.com; s=arc-20160816; b=axv9qssoybdhNNK/cdvAib9oc94lKtHqQPyQBkBljp8rI7PKYjZ0Fbl0CDrQZRmHvp fkz2coGzHChsjmgT9iDY8FkDsixyKEVN3F1Y64VT9YzirtyBx1pQ84DdaYypwOwnF/bF Sgm1Ya4jLI1dfLkPZJS1M0cb02F/CjxvDx62jzMvlAnJJ8CMzPv9jIiShgWH6Jeesp14 1gyNpreXrVYpw+sO+MjmHWcqEHb5+xyL5+PToX8BEDo0FyBn6yFEPxd3t55SACL6SAH2 EZPT+PRj6VNsLsjYOE8XuHb3prpF4dIF8MblDhY8SdKH9O4lBK/RV0/4FkziyHBQr+qY qONw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :dkim-signature; bh=aBNOEK5JmznFe788VWdmCxb/E0ad0SoBOicyxzidG4M=; b=Dy7gQfqeNM5BUJpbR0WXfYTPTowB5hpZ24lY2qXodGkFZYhzyKacLFBZphEOi5a4AD ZavyaCMuhy90steVGJUjwdSo00jRexyVDcB7gvNI9FaTOnIhLpXrfFVjNUqVpOGBzjJQ 7ACytIYjsEUmbJlNGqB13vmIKh82LgkifjItlPPR3SzmL268Dv5f99HHlxNKvYnhjHgu uoAwmrKM0QPVs4uu47b3OvV4UT9s1CdqadpRyXkvjDilv0Fm1DvUQXLDVv6ZFzuT3HTv us1vBY6+hDauvNekAmRAgWmszpe7iW6yk713AqNs6ZSGkow7OK4snoGGVFrAHbFXBw6v MH6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@igalia.com header.s=20170329 header.b=hU6ZvLQL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id t9-20020a17090340c900b0015838a4fd9dsi10015596pld.64.2022.05.08.23.41.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 May 2022 23:41:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=fail header.i=@igalia.com header.s=20170329 header.b=hU6ZvLQL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0793018E861; Sun, 8 May 2022 23:38:52 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356919AbiEDUFR (ORCPT + 99 others); Wed, 4 May 2022 16:05:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39508 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230295AbiEDUFP (ORCPT ); Wed, 4 May 2022 16:05:15 -0400 Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14CFF1F612; Wed, 4 May 2022 13:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Subject:From:Cc:To: MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=aBNOEK5JmznFe788VWdmCxb/E0ad0SoBOicyxzidG4M=; b=hU6ZvLQLzt+mU2QbDsSwJAwG2K 30DuoWSMuIj8aO9pQO7xIlf0hPGS0L5OuRlGxcQJiRKoYSMAtroKV1MFv+B5r0Bpvx1Arl4UGvGgd KROrXNajwRwCgHJ6jdWZXZhRjoqYLiDyfNJ9pzlkh+9MgrMg3FSXUHo8A1m88XchRWcj5eugxuNVc +hZD4GEF0LfrUEaXFnM1KOSFiEZsuzMrcuhqMNV9yLhNNuljEXsV8sjTLMHgus+VC7fIB6uXkeBmx yTxrb17XAdg8JXbasw9OhBvqp88JRzHZk65H39flrqd2hbf2yt4OPFFvDY8rjlPzERcK9AWXYOlQw grP2V7AQ==; Received: from [179.113.53.197] (helo=[192.168.1.60]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1nmLBC-000BAC-K7; Wed, 04 May 2022 22:00:59 +0200 Message-ID: <427a8277-49f0-4317-d6c3-4a15d7070e55@igalia.com> Date: Wed, 4 May 2022 17:00:42 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: Catalin Marinas , will Deacon , "Michael Kelley (LINUX)" , Vitaly Kuznetsov , Marc Zyngier , mark.rutland@arm.com, Russell King , Ard Biesheuvel , broonie@kernel.org Cc: "linux-arm-kernel@lists.infradead.org" , linux-kernel , "linux-hyperv@vger.kernel.org" From: "Guilherme G. Piccoli" Subject: Should arm64 have a custom crash shutdown handler? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 Hi folks, this email is to ask feedback / trigger a discussion about the concept of custom crash shutdown handler, that is "missing" in arm64 while it's present in many architectures [mips, powerpc, x86, sh (!)]. Currently, when we kexec in arm64, the function machine_crash_shutdown() is called as a handler to disable CPUs and (potentially) do extra quiesce work. In the aforementioned architectures, there's a way to override this function, if for example an hypervisor wish to have its guests running their own custom shutdown machinery. For powerpc/mips, the approach is a generic shutdown function that might call other handler-registered functions, whereas x86/sh relies in the "machine_ops" structure, having the crash shutdown as a callback in such struct. The usage for that is very broad, but heavy users are hypervisors like Hyper-V / KVM (CCed Michael and Vitaly here for this reason). The discussion about the need for that in arm64 is from another thread [0], so before start implementing/playing with that, I'd like to ask ARM64 community if there is any feedback and in case it's positive, what is the best implementation strategy (struct callback vs. handler call), etc. I've CCed ARM64/ARM32 maintainers plus extra people I found as really involved with ARM architecture - sorry if I added people I shouldn't or if I forgot somebody (though the ARM mailing-list is CC). Cheers, Guilherme [0] https://lore.kernel.org/lkml/2787b476-6366-1c83-db80-0393da417497@igalia.com/ See the proposed option (b)