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=-10.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 A3D4CC64E7B for ; Tue, 1 Dec 2020 14:09:15 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1426620705 for ; Tue, 1 Dec 2020 14:09:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="U72i2AUF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1426620705 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=JMX1q8uv8eGQ0NWU+0qWCZhcjaJNlSNq4zQfffQQdng=; b=U72i2AUFhkd08kPt6h7B/jVYK GC0gwgsPYMJBvG4q+CZsiwVJACCHq6dIiyNYzjSb/x0kQTHnljeUZoYi0LLBrqzDMmjdKWTQ9qzDn VJl3XCyY/Tjd3rBHD5Nd4Mne4hGCxYxeK5+ml4h8e9ZMl/svgIHw97A8hPYyI5bECXa5lzr9WPf9S gniSWoLFT8PyN7Gs10chlUZpPcJUTmz9Ncqv9yRTeOmuMehIcJ+Re2Nx7P9wprRHSrfht8r3h6WP+ 58yXiKRZmuo11yg9as2W2zc4lhOXSMk3fzMi+y4lFx9xdQn1QQwGikRNW2iYEu/NAZFaxNdjmR8wi laPf74vjg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kk6Jv-0005KI-53; Tue, 01 Dec 2020 14:07:55 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kk6Js-0005JT-BL for linux-arm-kernel@lists.infradead.org; Tue, 01 Dec 2020 14:07:53 +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 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 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-Disposition: inline In-Reply-To: <20201201131913.u7m2eifvtus74dra@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201201_090752_442441_16DAD70D X-CRM114-Status: GOOD ( 25.03 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Lorenzo Pieralisi , kernel-team@android.com, Jonathan Corbet , Catalin Marinas , Sudeep Holla , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Suzuki K Poulose , James Morse , linux-arm-kernel@lists.infradead.org, Marc Zyngier , Tejun Heo , Dennis Zhou , Christoph Lameter , Will Deacon , kvmarm@lists.cs.columbia.edu, Julien Thierry 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 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel