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.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=no 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 5FE28C433FE for ; Mon, 7 Dec 2020 14:11:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3BAC7235F7 for ; Mon, 7 Dec 2020 14:11:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726730AbgLGOLo (ORCPT ); Mon, 7 Dec 2020 09:11:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37186 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726046AbgLGOLo (ORCPT ); Mon, 7 Dec 2020 09:11:44 -0500 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B425DC0613D1 for ; Mon, 7 Dec 2020 06:11:28 -0800 (PST) Received: by mail-wr1-x441.google.com with SMTP id y17so3477887wrr.10 for ; Mon, 07 Dec 2020 06:11:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=kIglN2ENPr7zZxCKU9K9FdFhtb6JGzaE8AjsYQ4PtZ4=; b=Xhc60KBVbnArBSefinJI+TleN6X7aSEsNC0tQlYENBG2ZPPq9HpuIQyl0v3s77lz4d NaMMqkGUk2Y6w0tvbOkQAG1I6KgVd7yT8Wffq4xZm8NRs0HSBoivHZie/1RGmt2n3epv FWlxQlQGrjPu/b46XKseWpoWCCzY5a8gSoyHbAKyk7rvq6JkalR11VCCD+mz9yo/uYLt /GNmeSpjO/bd11ul7t0LgHnVA+wEfaLMtlihFIarwy5Cyr5nU64+sqY0OE8VOWKzZlX0 3JRdkzVznY/XSjGX9AlOwFk42GHr6PPa4BxCms3CvL/Valg4Rg86Mypisvmqg2JBHR3o XV0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kIglN2ENPr7zZxCKU9K9FdFhtb6JGzaE8AjsYQ4PtZ4=; b=KokFI9JKjSNHKvJCRstoRrzj59ZqUYDCxZ3bHYZSqccXV4kuym/t7bBCWqNKuu73Yi KYaYtV6MqUs9QtEvYHt+AOb8wnwAQ7myAp5ZP7eoV4LoBOPsGHTwecv0FobgLpnx09W+ i/j4g4Q4+dS57PqQKWRiJXKkmFH6IDLGHqc2J5WAvoenzkPlwVFec0bURLsInULtDcff pkgg+s+Rwd+SmPXAkDwEHZOcrA+3cxvRPNKzFlx/iH0P9m7X3qo8CqVXQ/+5xJkXTZpg R54MZpw2TO5qGgbJdthvJqrnkXwksYitcoowadiSvFBpiZ/r0vcTt2ajym1TolSGhxw+ ZjAw== X-Gm-Message-State: AOAM530GE6VbbI5iZCkaxrrhMKypc8Ds/vSAXNMmCYbhsDYQGFTkm/V9 JUh/w7+USoKpO7J428wqLaQvIQ== X-Google-Smtp-Source: ABdhPJwy02g4n9Bw93wn8robHfmfXCvn8HmKD427RxXtDweC+OQzf6Bi6J3mgHqERGzkgRm3qn05dQ== X-Received: by 2002:adf:fdc7:: with SMTP id i7mr17832777wrs.398.1607350287293; Mon, 07 Dec 2020 06:11:27 -0800 (PST) Received: from google.com ([2a00:79e0:d:210:f693:9fff:fef4:a7ef]) by smtp.gmail.com with ESMTPSA id z2sm3072994wml.23.2020.12.07.06.11.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Dec 2020 06:11:26 -0800 (PST) Date: Mon, 7 Dec 2020 14:11:20 +0000 From: Quentin Perret To: Will Deacon Cc: Catalin Marinas , Marc Zyngier , James Morse , Julien Thierry , Suzuki K Poulose , Rob Herring , Frank Rowand , "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , open list , "open list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE" , kernel-team@android.com, android-kvm@google.com Subject: Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection Message-ID: References: <20201117181607.1761516-1-qperret@google.com> <20201117181607.1761516-17-qperret@google.com> <20201207134052.GA4563@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201207134052.GA4563@willie-the-truck> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Monday 07 Dec 2020 at 13:40:52 (+0000), Will Deacon wrote: > Why not use the RESERVEDMEM_OF_DECLARE() interface for the hypervisor > memory? That way, the hypervisor memory can either be statically partitioned > as a carveout or allocated dynamically for us -- we wouldn't need to care. Yup, I did consider that, but the actual amount of memory we need to reserve for the hypervisor depends on things such as the size of struct hyp_page, which depends on the kernel you're running (that is, it might change over time). So, that really felt like something the kernel should be doing, to keep the DT backward compatible, ... Or did you have something more elaborate in mind? Thanks, Quentin