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 X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F951C83018 for ; Tue, 1 Dec 2020 14:09:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BA48520757 for ; Tue, 1 Dec 2020 14:09:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387669AbgLAOIe (ORCPT ); Tue, 1 Dec 2020 09:08:34 -0500 Received: from foss.arm.com ([217.140.110.172]:43596 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387443AbgLAOIc (ORCPT ); Tue, 1 Dec 2020 09:08:32 -0500 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 F2F0A30E; Tue, 1 Dec 2020 06:07:46 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.30.155]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 03C943F718; Tue, 1 Dec 2020 06:07:42 -0800 (PST) Date: Tue, 1 Dec 2020 14:07:34 +0000 From: Mark Rutland To: David Brazdil Cc: Sudeep Holla , kvmarm@lists.cs.columbia.edu, Jonathan Corbet , Catalin Marinas , Will Deacon , Marc Zyngier , James Morse , Julien Thierry , Suzuki K Poulose , Dennis Zhou , Tejun Heo , Christoph Lameter , Lorenzo Pieralisi , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kernel-team@android.com Subject: Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter Message-ID: <20201201140734.GA86881@C02TD0UTHF1T.local> References: <20201126155421.14901-1-dbrazdil@google.com> <20201126155421.14901-7-dbrazdil@google.com> <20201127163254.zxdrszlveaxhluwn@bogus> <20201201131913.u7m2eifvtus74dra@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201201131913.u7m2eifvtus74dra@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Tue, Dec 01, 2020 at 01:19:13PM +0000, David Brazdil wrote: > Hey Sudeep, > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > > > index 526d65d8573a..06c89975c29c 100644 > > > --- a/Documentation/admin-guide/kernel-parameters.txt > > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > > @@ -2259,6 +2259,11 @@ > > > for all guests. > > > Default is 1 (enabled) if in 64-bit or 32-bit PAE mode. > > > > > > + kvm-arm.protected= > > > + [KVM,ARM] Allow spawning protected guests whose state > > > + is kept private from the host. Only valid for non-VHE. > > > + Default is 0 (disabled). > > > + > > > > Sorry for being pedantic. Can we reword this to say valid for > > !CONFIG_ARM64_VHE ? I read this as valid only for non-VHE hardware, it may > > be just me, but if you agree please update so that it doesn't give remote > > idea that it is not valid on VHE enabled hardware. > > > > I was trying to run this on the hardware and was trying to understand the > > details on how to do that. > > I see what you're saying, but !CONFIG_ARM64_VHE isn't accurate either. The > option makes sense if: > 1) all cores booted in EL2 > == is_hyp_mode_available() > 2) ID_AA64MMFR1_EL1.VH=0 or !CONFIG_ARM64_VHE > == !is_kernel_in_hyp_mode() > > The former feels implied for KVM, the latter could be 'Valid if the kernel > is running in EL1'? WDYT? I reckon we can avoid the restriction if we instead add an early stub like with have for KASLR. That way we could parse the command line early, and if necessary re-initialize EL2 and drop to EL1 before the main kernel has to make any decisions about how to initialize things. That would allow us to have a more general kvm-arm.mode option where a single kernel Image could support: * "protected" mode on nVHE or VHE HW * "nvhe" mode on nVHE or VHE HW * "vhe" mode on VHE HW ... defaulting to VHE/nVHE modes depending on HW support. That would also be somewhat future-proof if we have to add other variants of protected mode in future, as we could extend the mode option with parameters for each mode. Thanks, Mark.