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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,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 29DA4C433E0 for ; Fri, 19 Feb 2021 18:34:56 +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 DF2AC64E54 for ; Fri, 19 Feb 2021 18:34:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DF2AC64E54 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=x9Qu61Qq33d1gyzwsi9+xx7Ph4JqQwPl5rtmdp+M4Ww=; b=bQYgc+7W9neyPE2guTuxWx2pc TjfmB8sULuR0ZZCC1QKb6RavcRs+g0faQyW83qCHAkuvdkwjl2dCP4R7LVn+EoVXBb3/5PCp8bp+U q+Mzm3eDqbq1x3zY6JtN4AN0xXEHiSptgywD02x5GK3U4S/sHnQtOtY+Md4Q0DDEAXhy1l1lv2qzV j6FUzu4zc1VPHdu+d9DuYaW6Xb47HYjIFUYNk2xDz+9cXP2j4jZGSMIO+yxBsIePLKhxr/b+Vve/W IGAkel3EZT7KwtEY6mjhENnmrsNkeLNehH9VSZlRKe9WNEiKWGpwF3noHIKeMTtfqZtIOS5ODt2Nw 4WJEiAqgg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lDAaW-0001eo-Gj; Fri, 19 Feb 2021 18:33:12 +0000 Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lDAaU-0001eK-AH for linux-arm-kernel@lists.infradead.org; Fri, 19 Feb 2021 18:33:11 +0000 Received: by mail-pl1-x630.google.com with SMTP id a9so3822376plh.8 for ; Fri, 19 Feb 2021 10:33:08 -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=apaYLCgpKww0D9oOCdL1/leTpd02z3P4w+UfyB0qUtE=; b=cNzmU6RwCi2M7zc1iN6kXALpuF4Dr3p9TUe2IZrVSxDRNZxj43w4OZN9GBVNUyVoGY H1RXDjVYIy/K8yNu7pM4zNUC+X8IPbISNDZkI7CMRH6NW31SInd7dD92i1llEAJIpNl9 iWbI8rgOSf7uQmj0SebJ6NcX/Ooy0yvSHYo1XyOoSpU19UIDftAZr4ACUicBtUMeLzOs JxUyV+lfMm+gr31mLh9yWgpO+USuw7r8q/XR26xRmrLSWdm95R71UclAbHcjdoD9mUVg /RXbSkNXY3aLx0dVZoac6BkHs3HET/aQxjW2WzpvO3e5JjAUaXvXTBmMVyOyA+7Xdb05 6Cfg== 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=apaYLCgpKww0D9oOCdL1/leTpd02z3P4w+UfyB0qUtE=; b=reLXk7L3ZgfJBQImJ1ZuxfCpyqXoSBX/R9pJnUDuLbGZJil7x90iTBYUe52NZh5I7l xRItpfh9MZMeOOsp0p6oQ09JSxN192dvinF1GOEyHxTitjKrhHi1w5otVARQheg7fd3p 5/fC4B68088TrWplDjIRgR+LX/xqy/klrSJ8DE4dwg0szSarZMO9ckRaicmTr+vt9pzy viIhHAj3IxnCYmnc38NNmbc+Qs2qY++0uqgYRUgK9FzQ9/MSkEh9GJHsFQeAVddOxYHT yfAiUtzpRrGvWPQD5CqDX2/5jYFX9Zg0nFjngXkJhvpEAqN7ExpDuehDXwN05dwmUpbo 1XUA== X-Gm-Message-State: AOAM531MLQ8XoW+1gLpgQTeC2cv6LGR6n9TGJ61iVH8nzfuGBE2ilq+Z ed2svVMdOdxzY/e6cUAzpN3c+w== X-Google-Smtp-Source: ABdhPJzGsluCsG7fkC2FvoTQGUbPeiWB8QuireUSeDuRRKhKexRWjsorjPjofN2X3s0CAIhvLZ+5ZQ== X-Received: by 2002:a17:902:9894:b029:e3:7aa3:a499 with SMTP id s20-20020a1709029894b02900e37aa3a499mr3088340plp.11.1613759586653; Fri, 19 Feb 2021 10:33:06 -0800 (PST) Received: from google.com ([2620:15c:f:10:fc4d:e9c3:d7d:9cb3]) by smtp.gmail.com with ESMTPSA id 3sm9467713pjk.26.2021.02.19.10.33.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Feb 2021 10:33:06 -0800 (PST) Date: Fri, 19 Feb 2021 10:32:58 -0800 From: Sean Christopherson To: Will Deacon Subject: Re: [RFC PATCH v2 16/26] KVM: arm64: Prepare Hyp memory protection Message-ID: References: <20210108121524.656872-1-qperret@google.com> <20210108121524.656872-17-qperret@google.com> <20210203143709.GA18907@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210203143709.GA18907@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210219_133310_450061_BA5B0F28 X-CRM114-Status: GOOD ( 26.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: Mark Rutland , devicetree@vger.kernel.org, kernel-team@android.com, Suzuki K Poulose , android-kvm@google.com, Catalin Marinas , Quentin Perret , Fuad Tabba , linux-kernel@vger.kernel.org, Rob Herring , James Morse , linux-arm-kernel@lists.infradead.org, Marc Zyngier , David Brazdil , Frank Rowand , 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 Wed, Feb 03, 2021, Will Deacon wrote: > On Fri, Jan 08, 2021 at 12:15:14PM +0000, Quentin Perret wrote: ... > > +static inline unsigned long hyp_s1_pgtable_size(void) > > +{ ... > > + res += nr_pages << PAGE_SHIFT; > > + } > > + > > + /* Allow 1 GiB for private mappings */ > > + nr_pages = (1 << 30) >> PAGE_SHIFT; > > SZ_1G >> PAGE_SHIFT Where does the 1gb magic number come from? IIUC, this is calculating the number of pages needed for the hypervisor's Stage-1 page tables. The amount of memory needed for those page tables should be easily calculated, and assuming huge pages can be used, should be far less the 1gb. > > + nr_pages = __hyp_pgtable_max_pages(nr_pages); > > + res += nr_pages << PAGE_SHIFT; > > + > > + return res; ... > > +void __init kvm_hyp_reserve(void) > > +{ > > + u64 nr_pages, prev; > > + > > + if (!is_hyp_mode_available() || is_kernel_in_hyp_mode()) > > + return; > > + > > + if (kvm_get_mode() != KVM_MODE_PROTECTED) > > + return; > > + > > + if (kvm_nvhe_sym(hyp_memblock_nr) < 0) { > > + kvm_err("Failed to register hyp memblocks\n"); > > + return; > > + } > > + > > + sort_memblock_regions(); > > + > > + /* > > + * We don't know the number of possible CPUs yet, so allocate for the > > + * worst case. > > + */ > > + hyp_mem_size += NR_CPUS << PAGE_SHIFT; Is this for per-cpu stack? If so, what guarantees a single page is sufficient? Mostly a curiosity question, since it looks like this is an existing assumption by init_hyp_mode(). Shouldn't the required stack size be defined in bytes and converted to pages, or is there a guarantee that 64kb pages will be used? > There was a recent patch bumping NR_CPUs to 512, so this would be 32MB > with 64k pages. Is it possible to return memory to the host later on once > we have a better handle on the number of CPUs in the system? Does kvm_hyp_reserve() really need to be called during bootmem_init()? What prevents doing the reservation during init_hyp_mode()? If the problem is that pKVM needs a single contiguous chunk of memory, then it might be worth solving _that_ problem, e.g. letting the host donate memory in N-byte chunks instead of requiring a single huge blob of memory. > > + hyp_mem_size += hyp_s1_pgtable_size(); _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel