From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1m2v7a-0005Fn-Kl for mharc-grub-devel@gnu.org; Mon, 12 Jul 2021 08:33:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41296) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2v7Y-00058W-AB for grub-devel@gnu.org; Mon, 12 Jul 2021 08:33:12 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:27620) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2v7W-0002Nj-Hn for grub-devel@gnu.org; Mon, 12 Jul 2021 08:33:12 -0400 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16CC3rgw063962; Mon, 12 Jul 2021 08:33:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=1vmIYQ3YKksxpnr6dtWLJxHCiME8iyvgALJ7Qqarfqw=; b=hs1I9kZ/C166YBBnSC0AIhtcxOtTA7Y1MKFbyBxfrCBFhe1ucvEAmYYyT6tb1xMAIsCx tUBp/fxnbeaJK3Sp6X1K5TJTa6k2HwhY+P4hw7p5fjktSmYBqLtoha8i+3Gz4RIkirW7 S1f++yfMqrxlJugeVFg5QVtxuxlALd2uoeLXedjIrbQgWGGkHsdRKIq1exos81TmpMqN NutxFUn8q5FLWhyxEdYkU/x00YLfW1cpxCOKJL2tTL3rQKBqO7SU+3I8Ef1Z9wQFm++y A3UOWViV3cRBI6J8r2OBrOEkdld9gPp1W7iSpUfrcc3ZaL9FXvnDAbO7nqXE9zuU/HbE LA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 39qrhyrvhh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Jul 2021 08:33:06 -0400 Received: from m0098410.ppops.net (m0098410.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 16CC6TN9092458; Mon, 12 Jul 2021 08:33:05 -0400 Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0a-001b2d01.pphosted.com with ESMTP id 39qrhyrvh1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Jul 2021 08:33:05 -0400 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 16CCS0qE004863; Mon, 12 Jul 2021 12:33:04 GMT Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by ppma03wdc.us.ibm.com with ESMTP id 39q36a2mc7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Jul 2021 12:33:04 +0000 Received: from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com [9.57.199.106]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 16CCX49U41157072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Jul 2021 12:33:04 GMT Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1193F2805E; Mon, 12 Jul 2021 12:33:04 +0000 (GMT) Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0A0272806A; Mon, 12 Jul 2021 12:33:04 +0000 (GMT) Received: from [9.47.158.152] (unknown [9.47.158.152]) by b01ledav001.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 12 Jul 2021 12:33:03 +0000 (GMT) Subject: Re: [PATCH v2 01/22] ieee1275: drop HEAP_MAX_ADDR, HEAP_MIN_SIZE To: The development of GNU GRUB , Daniel Axtens Cc: rashmica.g@gmail.com, alastair@d-silva.org, nayna@linux.ibm.com References: <20210630084031.2663622-1-dja@axtens.net> <20210630084031.2663622-2-dja@axtens.net> From: Stefan Berger Message-ID: Date: Mon, 12 Jul 2021 08:33:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210630084031.2663622-2-dja@axtens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: bwsVrOwoNHLaR5Zvx9RUBNIEANOnTa9e X-Proofpoint-GUID: M1z33NIV5LMj0ZJA7-uVx_sLHX0mkiQV X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-12_05:2021-07-12, 2021-07-12 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxlogscore=999 suspectscore=0 phishscore=0 spamscore=0 malwarescore=0 bulkscore=0 impostorscore=0 mlxscore=0 clxscore=1011 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107120094 Received-SPF: pass client-ip=148.163.156.1; envelope-from=stefanb@linux.ibm.com; helo=mx0a-001b2d01.pphosted.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.479, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 12:33:13 -0000 On 6/30/21 4:40 AM, Daniel Axtens wrote: > HEAP_MAX_ADDR is confusing. Currently it is set to 32MB, except > on ieee1275 on x86, where it is 64MB. > > There is a comment which purports to explain it: > > /* If possible, we will avoid claiming heap above this address, because it > seems to cause relocation problems with OSes that link at 4 MiB */ > > This doesn't make a lot of sense when the constants are well above 4MB > already. It was not always this way. Prior to > commit 7b5d0fe4440c ("Increase heap limit") in 2010, HEAP_MAX_SIZE and > HEAP_MAX_ADDR were indeed 4MB. However, when the constants were increased > the comment was left unchanged. > > It's been over a decade. It doesn't seem like we have problems with > claims over 4MB on powerpc or x86 ieee1275. (sparc does things completely > differently and never used the constant.) > > Drop the constant and the check. > > The only use of HEAP_MIN_SIZE was to potentially override the > HEAP_MAX_ADDR check. It is now unused. Remove it. > > Signed-off-by: Daniel Axtens I tested this patch and the other 2 memory related patches in a ppc64 QEMU VM where I need them for getting more memory for trusted boot enablement on ppc64. Without these patches it runs out of memory. From what I can see they work fine. Tested-by: Stefan Berger > --- > grub-core/kern/ieee1275/init.c | 17 ----------------- > 1 file changed, 17 deletions(-) > > diff --git a/grub-core/kern/ieee1275/init.c b/grub-core/kern/ieee1275/init.c > index d483e35eed2b..c5d091689f29 100644 > --- a/grub-core/kern/ieee1275/init.c > +++ b/grub-core/kern/ieee1275/init.c > @@ -45,9 +45,6 @@ > #include > #endif > > -/* The minimal heap size we can live with. */ > -#define HEAP_MIN_SIZE (unsigned long) (2 * 1024 * 1024) > - > /* The maximum heap size we're going to claim */ > #ifdef __i386__ > #define HEAP_MAX_SIZE (unsigned long) (64 * 1024 * 1024) > @@ -55,14 +52,6 @@ > #define HEAP_MAX_SIZE (unsigned long) (32 * 1024 * 1024) > #endif > > -/* If possible, we will avoid claiming heap above this address, because it > - seems to cause relocation problems with OSes that link at 4 MiB */ > -#ifdef __i386__ > -#define HEAP_MAX_ADDR (unsigned long) (64 * 1024 * 1024) > -#else > -#define HEAP_MAX_ADDR (unsigned long) (32 * 1024 * 1024) > -#endif > - > extern char _start[]; > extern char _end[]; > > @@ -183,12 +172,6 @@ heap_init (grub_uint64_t addr, grub_uint64_t len, grub_memory_type_t type, > if (*total + len > HEAP_MAX_SIZE) > len = HEAP_MAX_SIZE - *total; > > - /* Avoid claiming anything above HEAP_MAX_ADDR, if possible. */ > - if ((addr < HEAP_MAX_ADDR) && /* if it's too late, don't bother */ > - (addr + len > HEAP_MAX_ADDR) && /* if it wasn't available anyway, don't bother */ > - (*total + (HEAP_MAX_ADDR - addr) > HEAP_MIN_SIZE)) /* only limit ourselves when we can afford to */ > - len = HEAP_MAX_ADDR - addr; > - > /* In theory, firmware should already prevent this from happening by not > listing our own image in /memory/available. The check below is intended > as a safeguard in case that doesn't happen. However, it doesn't protect