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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 357DFC74A4B for ; Mon, 13 Mar 2023 17:57:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229922AbjCMR5J (ORCPT ); Mon, 13 Mar 2023 13:57:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229537AbjCMR5H (ORCPT ); Mon, 13 Mar 2023 13:57:07 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BCF84C6D6; Mon, 13 Mar 2023 10:57:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 47068B811C1; Mon, 13 Mar 2023 17:57:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 034B6C433D2; Mon, 13 Mar 2023 17:57:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678730224; bh=eFp7TWEtaCJ4IREd5Nn0VB8e77L9rWYXxBrgS5//W4c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=nHezHnwzVlRd/r0ojenNatH1I7jMw4BA07iPhJjEx5vBqBlqH19+stw5Kwuw3kDrx 5efKwsI4zqVE+fiX/eSqAfFTT6hZb2ousH5S7CjtwvCaRxzsGwoh3HRuIkH5E7GAl8 K/5IJQ9b7ECDCwC9A6BquVmXt+usKuqN3MFZIaaaiNDRSohAUuN27/jL+G6nQ+SDqf aF/hd+4PTjJnjA3OOSMc3hHnJH4TNSZzw3NsQidscnjljNB86QlIWs3Fc/02OEzUQO PfDZQdJGJnF6Iuq/eQXRnlFb0vD4I7pp+pK26YpM92qKzWuZNSyGMdwBUd/PIQdqDs ObZUU018dqfkQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pbmPt-00HKeC-If; Mon, 13 Mar 2023 17:57:01 +0000 Date: Mon, 13 Mar 2023 17:57:00 +0000 Message-ID: <86jzzky1oz.wl-maz@kernel.org> From: Marc Zyngier To: Sean Christopherson Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , kvmarm@lists.linux.dev, Huacai Chen , Aleksandar Markovic , Anup Patel , Atish Patra , kvm-riscv@lists.infradead.org Subject: Re: [PATCH 2/2] KVM: Don't enable hardware after a restart/shutdown is initiated In-Reply-To: References: <20230310221414.811690-1-seanjc@google.com> <20230310221414.811690-3-seanjc@google.com> <87fsaa5kyv.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: seanjc@google.com, pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, kvmarm@lists.linux.dev, chenhuacai@kernel.org, aleksandar.qemu.devel@gmail.com, anup@brainfault.org, atishp@atishpatra.org, kvm-riscv@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 13 Mar 2023 15:02:27 +0000, Sean Christopherson wrote: > > On my todo list is to better understand whether or not the other architectures > that utilize the generic hardware enabling (ARM, RISC-V, MIPS) truly need to disable > virtualization during a reboot, versus KVM simply being polite. E.g. on x86, if VMX > is left enabled, reboot may hang depending on how the reboot is performed. If > other architectures really truly need to disable virtualization, then they likely > need something similar to x86's emergency reboot shenanigans. At least pre-CCA, there isn't much to do, because there is no such thing as "disabling virtualisation". For kexec, the only things we need to do are to go back to EL2 in the nVHE case, and in any case to put all other CPUs back into the firmware (PSCI CPU_OFF). CCA may well add other things into the picture, because it is a parallel exception level that KVM doesn't really control. That's one of the many open questions I have about this "lovely" piece of architecture. Of course, if we were to completely ignore CCA and instead use the underlying HW (aka RME), things would be a lot simpler and we'd be back to my original statement... M. -- Without deviation from the norm, progress is not possible.