From patchwork Wed Sep 14 07:41:51 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peng Fan X-Patchwork-Id: 9330655 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0244F607FD for ; Wed, 14 Sep 2016 07:44:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E913429A7E for ; Wed, 14 Sep 2016 07:44:26 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DDCF429A80; Wed, 14 Sep 2016 07:44:26 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 078C729A7E for ; Wed, 14 Sep 2016 07:44:24 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bk4pb-0000d0-Ds; Wed, 14 Sep 2016 07:42:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bk4pa-0000cq-9b for xen-devel@lists.xen.org; Wed, 14 Sep 2016 07:42:06 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id 5A/B4-15788-D4FF8D75; Wed, 14 Sep 2016 07:42:05 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRWlGSWpSXmKPExsVyMfSOs67P/xv hBq87rCyWfFzM4sDocXT3b6YAxijWzLyk/IoE1owNnX1sBYdMKjqfzWVqYNyo3cXIySEk0M8o sWpKSBcjFweLwHxWiRdHb7OBOBICu1klHnQ8ZwWpkhCIkVg+tYMJwq6UmL98JyNEt4rE3E09j CANQgLTmCT+nG9mBkmwCKhKnLv+CsxmE1CTOPJ+JliDiIC6xJ8LE8BsZoFAiX8tD8GGCgv4Sn R/3AC2jFfARGLlwWesEAsKJHqf/mCDiAtKnJz5hAWiV0vixr+XQL0cQLa0xPJ/HCBhTgFricf zTzKChEWBbnt1sH4Co/AsJM2zkDTPQmhewMi8ilGjOLWoLLVI19BSL6koMz2jJDcxM0fX0MBY Lze1uDgxPTUnMalYLzk/dxMjMMjrGRgYdzD+Pu53iFGSg0lJlLfX/0a4EF9SfkplRmJxRnxRa U5q8SFGGQ4OJQlep39AOcGi1PTUirTMHGC8waQlOHiURHg//AZK8xYXJOYWZ6ZDpE4xGnNs+X 1tLRPHtqn31jIJseTl56VKifP++wtUKgBSmlGaBzcIlgYuMcpKCfMyMjAwCPEUpBblZpagyr9 iFOdgVBLm9QS5hyczrwRu3yugU5iATtmy5jrIKSWJCCmpBkb3VV/n3Lx7XEXt9bzwb47V8rNq g9n7nR+IC2x/7aBUqRn0YM/V61PiJxbYr5ZjXttcytXocDe87wR/ZQ2/zaVZYX1WHjkuq2u+q t3TfedrzROR/+zAsmWxIuZd/FPzrjPuOGYUIaXNx5z7UXdJVqTj9x35K3Tz5FWtHMJzKl1EK4 ++EJzrpcRSnJFoqMVcVJwIANRMJ6r+AgAA X-Env-Sender: van.freenix@gmail.com X-Msg-Ref: server-13.tower-31.messagelabs.com!1473838923!60020800!1 X-Originating-IP: [209.85.220.67] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 8.84; banners=-,-,- X-VirusChecked: Checked Received: (qmail 51944 invoked from network); 14 Sep 2016 07:42:04 -0000 Received: from mail-pa0-f67.google.com (HELO mail-pa0-f67.google.com) (209.85.220.67) by server-13.tower-31.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 14 Sep 2016 07:42:04 -0000 Received: by mail-pa0-f67.google.com with SMTP id oz2so356699pac.0 for ; Wed, 14 Sep 2016 00:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=m5ZBVmoGbK8cJYzKAMc0Zxq05dTr+DNI9Y2+oBn3q0g=; b=R2pkKa70gh16v35pnBrCYGnxTwlM8xy1RJHeJljaQufz29KPJgzsI2ZsO9cQKEMKPC Wsr54WvWPN0BJujE8FQkXLf0/zUMmaiF08byqqG2hDsMhcQZBt+V4/1yH982yosikK3t Gs121TAqIVgvFkVeeAbBtetljlnLyYMwTCi/FoOoKLItZ20Y41DHtz0ysWWAdT1X6Vx6 qa3E7HZRAWG0SQO3LdPp2/mm4I1hR7AtlZbDlSlQ2EiEIr2jejmJMvfmNyWcjPPqkfu6 9dMti67xWjHBUvNbPvXqPtVTT2/6vGKDzLqTWmfXjONbH3hrUWxKXWl3M7RgqMrJgVFZ ZGsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=m5ZBVmoGbK8cJYzKAMc0Zxq05dTr+DNI9Y2+oBn3q0g=; b=PzNTtIx7RJrVASSs4YYhUGptyvG4PO9URBhWosi126E46yloGTI3zYXxYFeq/ALBuf nG14H0hwGzpOCkZzZViaUaoZ7PbBZiPFTDUE9j4TMkkuLTt35LxkR/TFR6YMbCTZIqpx yjF+G4C6K/JlPshgONgN/Z3OfaM2g92b2QBeOO9hjzeqLnQ/BtyrbvulWGmBUZdqlMR/ cXvZu33yxQfrneYZDUrlUtCTEYX1oJaZXDc90UmvKQCBYFydjmJSoea1LRd29vdiZe2t oUenfdbEn3d2nrisKMGOiKhub6CUHGXhyK7EakBhVCdp9f6wv5bg/DeNfR6BUjtuBPZr GC9Q== X-Gm-Message-State: AE9vXwNmA96NmCLY6328+9WkgbXLqSxqKjBRdlGblQvbT3cCtgII6WsBYdcE4q0PKPCXzQ== X-Received: by 10.66.161.225 with SMTP id xv1mr2115576pab.20.1473838923083; Wed, 14 Sep 2016 00:42:03 -0700 (PDT) Received: from linux-7smt.suse (gate-zmy3.freescale.com. [192.88.167.1]) by smtp.googlemail.com with ESMTPSA id q4sm35798755pfb.18.2016.09.14.00.41.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Sep 2016 00:42:02 -0700 (PDT) Date: Wed, 14 Sep 2016 15:41:51 +0800 From: Peng Fan To: Julien Grall Message-ID: <20160914074149.GA28922@linux-7smt.suse> References: <1473829949-21481-1-git-send-email-peng.fan@nxp.com> <703bbeda-8302-822c-3bc7-fcb94951f138@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <703bbeda-8302-822c-3bc7-fcb94951f138@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Cc: Peng Fan , sstabellini@kernel.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH V1] xen/arm: domain_build: introduce dom0_lowmem bootargs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP Hello Julien, On Wed, Sep 14, 2016 at 08:23:24AM +0100, Julien Grall wrote: >Hello, > >On 14/09/2016 06:12, Peng Fan wrote: >>On AArch64 SoCs, some IPs may only have the capability to access >>32bits address space. The physical memory assigned for Dom0 maybe >>not in 4GB address space, then the IPs will not work properly. >> >>Introduce dom0_lowmem bootargs, user could pass "dom0_lowmem=xx" >>to xen. It means how much memory user would like to be allocated >>in lower 4GB memory space. If there is not enough memory for >>dom0_lowmem, higher memory will be allocated. >> >>Thinking such a memory layout on an AArch64 SoC: >>Region 0: 2GB(0x80000000 - 0xffffffff) >>Region 1: 4GB(0x880000000 - 0x97fffffff) >>If user would like to assign 2GB for Dom0 and 1GB of the 2GB memory >>in Region 0, user could pass "dom0=2048M dom0_lowmem=1024M" to xen. > >See my comments on v1, I still don't think this new parameter is useful. Thanks for comments. I see :) > >The commit message does not explain what is the advantage to only allocate a >bit of low mem and not as much as we can (as we do on for 32-bit dom0). This patch is just want to resolve the issue in https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html. I am not keen on the method in this patch, a bit complicated. The method in this patch is try to allocate the size lowmem indicated in bootargs. Rethinking about DomU, seems allocate as much as possible lowmem for Dom0 is ok. Then, do you agree to use the following patch? Pass "dom0_use_lowmem=1" to xen to allocate lowmem as much as possible. > >> >>Signed-off-by: Peng Fan >>Cc: Stefano Stabellini >>Cc: Julien Grall >>--- >> >>RFC->V1: >> This patch is to resolve the issue in https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html >> No code change since RFC. >> Tested on xen-4.8 unstable with AArch64. See partial log: >> "dom0_mem = 2048M dom0_lowmem=128M" >> (XEN) Allocated 0x00000088000000-0x00000090000000 (128MB/2048MB, order 15) >> (XEN) Allocated 0x00000880000000-0x000008c0000000 (1024MB/1920MB, order 18) >> (XEN) Allocated 0x000009c0000000-0x000009e0000000 (512MB/896MB, order 17) >> (XEN) Allocated 0x000009e0000000-0x000009f0000000 (256MB/384MB, order 16) >> (XEN) Allocated 0x000008f8000000-0x00000900000000 (128MB/128MB, order 15) >> >> "dom0_mem = 2048M dom0_lowmem=1024M" >> (XEN) Allocated 0x000000a0000000-0x000000c0000000 (512MB/2048MB, order 17) >> (XEN) Allocated 0x000000c0000000-0x000000e0000000 (512MB/1536MB, order 17) >> (XEN) Allocated 0x00000880000000-0x000008c0000000 (1024MB/1024MB, order 18) >> >> "dom0_mem = 1024M dom0_lowmem=1024M" >> (XEN) Allocated 0x000000a0000000-0x000000c0000000 (512MB/1024MB, order 17) >> (XEN) Allocated 0x000000c0000000-0x000000e0000000 (512MB/512MB, order 17) >> >> xen/arch/arm/domain_build.c | 30 +++++++++++++++++++++++++++++- >> 1 file changed, 29 insertions(+), 1 deletion(-) >> >>diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >>index 35ab08d..0f53bba 100644 >>--- a/xen/arch/arm/domain_build.c >>+++ b/xen/arch/arm/domain_build.c >>@@ -33,6 +33,8 @@ int dom0_11_mapping = 1; >> >> #define DOM0_MEM_DEFAULT 0x8000000 /* 128 MiB */ >> static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT; >>+/* Only for AArch64 */ >>+static u64 __initdata dom0_lowmem; >> >> static void __init parse_dom0_mem(const char *s) >> { >>@@ -42,6 +44,12 @@ static void __init parse_dom0_mem(const char *s) >> } >> custom_param("dom0_mem", parse_dom0_mem); >> >>+static void __init parse_dom0_lowmem(const char *s) >>+{ >>+ dom0_lowmem = parse_size_and_unit(s, &s); >>+} >>+custom_param("dom0_lowmem", parse_dom0_lowmem); >>+ >> //#define DEBUG_11_ALLOCATION >> #ifdef DEBUG_11_ALLOCATION >> # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args) >>@@ -244,7 +252,7 @@ static void allocate_memory(struct domain *d, struct kernel_info *kinfo) > >The comment on top of allocate_memory should be updated. > >> unsigned int order = get_11_allocation_size(kinfo->unassigned_mem); >> int i; >> >>- bool_t lowmem = is_32bit_domain(d); >>+ bool_t lowmem = is_32bit_domain(d) || !!dom0_lowmem; >> unsigned int bits; >> >> /* >>@@ -263,6 +271,9 @@ static void allocate_memory(struct domain *d, struct kernel_info *kinfo) >> * First try and allocate the largest thing we can as low as >> * possible to be bank 0. >> */ >>+ if ( dom0_lowmem ) >>+ order = get_order_from_bytes(dom0_lowmem); >>+ >> while ( order >= min_low_order ) >> { >> for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ ) >>@@ -278,6 +289,11 @@ static void allocate_memory(struct domain *d, struct kernel_info *kinfo) >> >> got_bank0: >> >>+ if ( dom0_lowmem ) { >>+ dom0_lowmem -= pfn_to_paddr((1 << order)); >>+ lowmem = is_32bit_domain(d) || !!dom0_lowmem; > >Why do you spread the lowmem = is_32_bit_domain(d) || !!dom0_lowmem >everywhere? If the first allocation does not allocate the needed lowmem, the following allocation will continue allocate lowmem. > >>+ } >>+ >> if ( !insert_11_bank(d, kinfo, pg, order) ) >> BUG(); /* Cannot fail for first bank */ >> >>@@ -325,6 +341,16 @@ static void allocate_memory(struct domain *d, struct kernel_info *kinfo) >> } >> } >> >>+ if ( dom0_lowmem && lowmem ) >>+ { >>+ dom0_lowmem -= pfn_to_paddr((1 << order)); >>+ lowmem = is_32bit_domain(d) || !!dom0_lowmem; >>+ } >>+ else >>+ { >>+ lowmem = false; >>+ } >>+ >> /* >> * Success, next time around try again to get the largest order >> * allocation possible. >>@@ -2098,6 +2124,8 @@ int construct_dom0(struct domain *d) >> >> d->max_pages = ~0U; >> >>+ BUG_ON(dom0_mem < dom0_lowmem); >>+ > >BUG_ON should not be used to check user input validity. Thanks, get it. Regards, Peng. diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 35ab08d..cc71e6f 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -28,6 +28,8 @@ static unsigned int __initdata opt_dom0_max_vcpus; integer_param("dom0_max_vcpus", opt_dom0_max_vcpus); +static bool_t __initdata opt_dom0_use_lowmem; +boolean_param("dom0_use_lowmem", opt_dom0_use_lowmem); int dom0_11_mapping = 1; @@ -244,7 +246,7 @@ static void allocate_memory(struct domain *d, struct kernel_info *kinfo) unsigned int order = get_11_allocation_size(kinfo->unassigned_mem); int i; - bool_t lowmem = is_32bit_domain(d); + bool_t lowmem = is_32bit_domain(d) || opt_dom0_use_lowmem; unsigned int bits;