[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH 2/2] xen/arm: Handle reserved heap pages in boot and heap allocator


  • To: Michal Orzel <michal.orzel@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Henry Wang <Henry.Wang@xxxxxxx>
  • Date: Tue, 30 Aug 2022 08:00:05 +0000
  • Accept-language: zh-CN, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QKXy+pqv6HZX8MVgwlffMbgObvTaFF30iGc17egXUD4=; b=AuWBJRSFB1AyISU44Aak6zhMOGb3w2i+de3hVLIn7AAnNLFLZgEJZJZv9SmziKc2V/6t9YdDX4pwwUe1bO7T+Rgqv/Ah0fYMnzm3hFx2MzEPJM8zUUXIyHv1UDXoB6maTbIQ8uk3DEPjUz8LvHXJUCxfMcTxrZiJkTo6PWT3IIfI7Y+0gjOuMOpQzHgn8LDNievoWm+lu6C+oOHzsDGuf168Tf0Ioln6tnER8QzIE2l67qDXRLeMkVgtToxkUba3wrfdrcl5aMD3CdPUH3L5JmPKNuqKNEk8LC35FgftWrM5Gzd7H7AaZWrhaOVkqi9+l5/XN7qYweuQlt5BGhJHaw==
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QKXy+pqv6HZX8MVgwlffMbgObvTaFF30iGc17egXUD4=; b=IE+bQjAReEYbYpVNW+NVULqaw+Fr3bcNIb7UbtaS2BnIdhznrgWMgx3XxWsVuDyCN/jMWjkCQ+GYfaMhNl9k12PZm7cjW/Vwvi664pcgjLxjo0Ap59plKQ60+Lr6zGtO4uitAPmfhUKuXZg0QXmraT8+pdjtfkq6itu5leHU++f0n68GwVEKX2z1CQ1LgcxcXMIHDuB81JrcPli9mYWt7g7f1zBqlW6Sv7UE7Z0qLsdgvgDQJ5Vt91vrv9S0okJv+fX2gkBqewJKfFCJNUOkYmTcjDdXbNsjJ95WlcX2me+F7fIWdjw9Sbphd2MAbxzBqZxzaKVks4GglLOC/fg0tQ==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=HZVObzAk4/yGUHoE9ezZF3/x1mDgyNb9MWi6jTPrl8mmAiawEAgXjcvlXzVy87Y19GVSheGxNDROyS+XVJ2DPLutDSmEyvKNdhHYFXtU+BcmzMSH0DIkJ2tvU+5BKp72HAupqTEU0lna54SpZQaNC2S/C03KE4Qxx4E1Yjl/fP2zz2m4YZKDJbJRBQyEwxcKDRPLlxQrMQ9Q17QW2E9lrxcVaXA+HkDtL6yLzxRM4qBcvdyjJIRTVf9S7ajrauEMbJCeBpSrrNSKf1Qxe4xSnSvYyVaReWdEwwnKTL+nnw5mWWE2LoLHRigX5oHwAwaApeubSgVUeo584DuuF0Fw8A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lOp9/no6uokcKysISZkgOY9GsEqFZcVc9xSMyTEshwkmzmG/R2UCKVHfDlBqwBw/C23lr+uI7Osjw+eIy6r7rUCKuY2/mR16gxDAmTtDElB/RQml2N6nii152oSqkPE94hu2zh3VK3Ro26jz5oV33G4MZwwFgiohrlF+gk4+z95HjZaCicslariSyw87Ia2DeYI+OvMkBpr/BH8ujxnMHbxnprqqvtd+IsT7IdBfMyM9b+tHMX1DZhqdhef1PjUL3TTrMakltasV3hcMnrMD5WkkTS2Z24/n6RqL0QH+HDl90q5QYXloZbaeRJMeHvQUaHpJrPgXNmiL+7gGhKAByQ==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Tue, 30 Aug 2022 08:01:59 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHYt4ugTfbCAM/WyEil7pMplK0r3q2/e0SAgAeAsxCAABaogIAAAyrg
  • Thread-topic: [PATCH 2/2] xen/arm: Handle reserved heap pages in boot and heap allocator

Hi Michal,

> -----Original Message-----
> From: Michal Orzel <michal.orzel@xxxxxxx>
> >>>
> >> Did you consider putting reserved_heap into bootinfo structure?
> >
> > Actually I did, but I saw current bootinfo only contains some structs so
> > I was not sure if this is the preferred way, but since you are raising this
> > question, I will follow this method in v2.
> This is what I think would be better but maintainers will have a decisive 
> vote.

Then let's wait for more input from maintainers.

> 
> >>>
> >>> -    if ( ! e )
> >>> -        panic("Not not enough space for xenheap\n");
> >>> +    if ( ! e ||
> >>> +         ( reserved_heap && reserved_heap_pages < 32<<(20-
> PAGE_SHIFT) ) )
> >> I'm not sure about this. You are checking if the size of the reserved heap 
> >> is
> >> less than 32MB
> >> and this has nothing to do with the following panic message.
> >
> > Hmmm, I am not sure if I understand your question correctly, so here there
> > are actually 2 issues:
> > (1) The double not in the panic message.
> > (2) The size of xenheap.
> >
> > If you check the comment of the xenheap constraints above, one rule of
> the
> > xenheap size is it "must be at least 32M". If I am not mistaken, we need to
> > follow the same rule with the reserved heap setup, so here we need to
> check
> > the size and if <32M then panic.
> This is totally fine. What I mean is that the check you introduced does not
> correspond
> to the panic message below. In case of reserved heap, its size is selected by
> the user.
> "Not enough space for xenheap" means that there is not enough space to be
> reserved for heap,
> meaning its size is too large. But your check is about size being too small.

Actually my understanding of "Not enough space for xenheap" is xenheap
is too large so we need to reserve more space, which is slightly different than
your opinion. But I am not the native speaker so it is highly likely that I am
making mistakes...

How about changing the panic message to "Not enough memory for xenheap"?
This would remove the ambiguity here IMHO.

> 
> >>> +     * If reserved heap regions are properly defined, (only) add these
> >> regions
> >> How can you say at this stage whether the reserved heap regions are
> defined
> >> properly?
> >
> > Because if the reserved heap regions are not properly defined, in the
> device
> > tree parsing phase the global variable "reserved_heap" can never be true.
> >
> > Did I understand your question correctly? Or maybe we need to change the
> > wording here in the comment?
> 
> FWICS, reserved_heap will be set to true even if a user describes an empty
> region
> for reserved heap. This cannot be consider a properly defined region for a
> heap.

Oh good point, thank you for pointing this out. I will change the comments
here to "If there are non-empty reserved heap regions". I am not sure if adding
an empty region check before setting the "reserved_heap" would be a good
idea, because adding such check would add another for loop to find a non-empty
reserved heap bank. What do you think?

Kind regards,
Henry

> 
> ~Michal

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.