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 AFA21C1B087 for ; Mon, 7 Dec 2020 14:12:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 94E11235F7 for ; Mon, 7 Dec 2020 14:12:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727358AbgLGOML (ORCPT ); Mon, 7 Dec 2020 09:12:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727274AbgLGOMJ (ORCPT ); Mon, 7 Dec 2020 09:12:09 -0500 Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4F3EC0613D2 for ; Mon, 7 Dec 2020 06:11:28 -0800 (PST) Received: by mail-wr1-x442.google.com with SMTP id r3so12902295wrt.2 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=kkN4c9vNTEZpgESP4gF9LjLpGK84vNruGNYZYXLNVQI36Q9Rsd71kXnxDcEeDicZEt A61Cwt1eu76b17DCyywaPiy9yympb8tAyQ6FKvoanN1uqXtjw6siZEVzt/fX9VlGvF+t AsIXg7yfPCHTRRe+dGfCPo7f18kPbw9RwIbB9zXtiSWpjYRb5VWZW0FQF5p3i5INueL2 pucIgTzmvQkB/k96Tg6R4rdjt+KylFbwyQUZDBGH5FoFNOkPoDdUjiZW9eRA93tI0noJ bhpbqCs+qu2D4IPikW7R6RuCi3k172njIJ78Eikjf7h5m2RXyhAgq/Vx9AQjs6Jttt+j VYdQ== X-Gm-Message-State: AOAM530lPvRVsAMlaZsVqH8yZbbSNJHHyhjdTd8dl85XhMAofYNEB3fF yeA1+hcraheFyEUCoP7D53ctkA== 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: linux-kernel@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 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=-0.6 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FSL_HELO_FAKE,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 45A1BC433FE for ; Mon, 7 Dec 2020 14:11:33 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id A5AC6235F9 for ; Mon, 7 Dec 2020 14:11:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5AC6235F9 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id DE1014B269; Mon, 7 Dec 2020 09:11:31 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlvNX4qLxxbN; Mon, 7 Dec 2020 09:11:31 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 045344B27F; Mon, 7 Dec 2020 09:11:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C28434B25E for ; Mon, 7 Dec 2020 09:11:29 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vIhZmtaJEGW for ; Mon, 7 Dec 2020 09:11:28 -0500 (EST) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 991B04B137 for ; Mon, 7 Dec 2020 09:11:28 -0500 (EST) Received: by mail-wr1-f66.google.com with SMTP id a12so6099863wrv.8 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=t50Y2lojmlBJMRaJZ6x45y+BUBdI4L3mfvLej7LvZDJ4VF8/CCYz6H/KgW/yuu77AZ FiOp6+yozKp06yfKweXZHI8MnPAHs/aujMnmwj7NOLTZRrBK4xAmIXx/xLrxnN1LY7cf MvKMNU0CzXAWnq+jGY7b9DyXpSMQ0660TM53ak9kOWFnQ6Wozr/xmt1/prAbX65RQKRS TbSH0DlmxiJUN3WFpP7+PhJk+tnAx0EbMixh3jE+YuAkUqsPM7K/SHy9VCMlG4JRyYG4 qr4tQoQ66vmq1y6fAZyASdOwXZ0+7jsJxIVKNom2LUYPQk0Iq6iv+VmaVen3ldTkT78Y GsGw== X-Gm-Message-State: AOAM533QkJWnHTF3Wgeh9AJzGlMEgJ4v1vOC4vcroxRfPuqMrNPF5gCp MwjHJdyFHdFtLDjka5z6D07JHQ== 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 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-Disposition: inline In-Reply-To: <20201207134052.GA4563@willie-the-truck> Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE" , kernel-team@android.com, android-kvm@google.com, Catalin Marinas , open list , Rob Herring , "moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)" , Marc Zyngier , Frank Rowand , "open list:KERNEL VIRTUAL MACHINE FOR ARM64 \(KVM/arm64\)" X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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=-0.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 43273C4361B for ; Mon, 7 Dec 2020 14:13:52 +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 E4033235DD for ; Mon, 7 Dec 2020 14:13:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E4033235DD Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.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=9yPJc+gtMQRdsMebkhoOXl5DTfO2fh/XXw3pKVaUoI4=; b=nksxFD2tRSbHZKIbLPc0xoYDN 4XQzu4IO9hxfXxrl9FJLKj6LxN7GYPbZ1UsDnyb2b7T8KZCiKerc7/4aU/59kN6SHn0D1xhwoNLCH unIowxG+SJdZKoVk5oQIdBoHO9bgkc3PBUzGWKp2ffgJw66FCVGMr7E8q9U1w0lfTerkjbyD+x6TA jbrlBU7d0p7C+V8NjufpCmPtHjT+KfxknZ03ZO+gTi7ovmqOzewL+dR3l8oYgtFwOTzrX9YetEDVV hy7Dka1w+itXnkNNQWtb9WhIgFEtigMjYlFYGOMj3WketGyewDbExAi1sbEjqKf12duoIlxYtL8yz H7TpB0pCw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmHFa-0003T0-Ib; Mon, 07 Dec 2020 14:12:26 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmHEe-00030L-MH for linux-arm-kernel@lists.infradead.org; Mon, 07 Dec 2020 14:11:29 +0000 Received: by mail-wr1-x443.google.com with SMTP id k14so12919087wrn.1 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=Es/bJJMUaXglbuZ+tc6zqA4mn6qc2wtmegeWgIffITd+OMb2OR7uycb3Jq75JvxAQU JswJozDNAE9iBRhF7DPfyCkAY+rN0BTAx/V9HllCwyLOw2KaZwJIGFpzUAZX8iNQhcMC 6FwUFQ5v28TGgWsb8hrgarNS9wNBSc3u2GOd68IAUOCZmGlG4U5mvt+4DNTBk4dSwq9G AnA0GVfF7/Njrf2DYmIHJTR+Vj+ZBKifVGBxA5Tl7yoKwFQ+htWPoN+jHzH1HRCE8CuU Qh++/mUlZ6og+r7HmLZ24HBdSANKEykH/DEwe7k3KO8nVntipfibWLPVe/xpss3YjxCU WYZA== X-Gm-Message-State: AOAM5334tcjB4zxeffEUGhaBJ1f4XZx6squHAE9ZPFc6m8Sa7sbIReoY hnThHstSHD3payEivxDd5oGDjw== 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 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-Disposition: inline In-Reply-To: <20201207134052.GA4563@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201207_091128_801134_6F039EA2 X-CRM114-Status: GOOD ( 13.05 ) 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: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE" , kernel-team@android.com, Suzuki K Poulose , android-kvm@google.com, Catalin Marinas , open list , Rob Herring , James Morse , "moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)" , Marc Zyngier , Frank Rowand , "open list:KERNEL VIRTUAL MACHINE FOR ARM64 \(KVM/arm64\)" , 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel