All of lore.kernel.org
 help / color / mirror / Atom feed
From: Henry Wang <Henry.Wang@arm.com>
To: Michal Orzel <michal.orzel@amd.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <Bertrand.Marquis@arm.com>,
	Wei Chen <Wei.Chen@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: RE: [PATCH 2/2] xen/arm: Handle reserved heap pages in boot and heap allocator
Date: Tue, 30 Aug 2022 08:00:05 +0000	[thread overview]
Message-ID: <AS8PR08MB7991BB31E34ADB02069AE87292799@AS8PR08MB7991.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <bc5eb855-0137-130b-e30b-7f4417798a93@amd.com>

Hi Michal,

> -----Original Message-----
> From: Michal Orzel <michal.orzel@amd.com>
> >>>
> >> 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

  reply	other threads:[~2022-08-30  8:02 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-24  7:31 [PATCH 0/2] Introduce reserved heap Henry Wang
2022-08-24  7:31 ` [PATCH 1/2] docs, xen/arm: Introduce reserved heap memory Henry Wang
2022-08-24 13:46   ` Michal Orzel
2022-08-25  1:04     ` Henry Wang
2022-08-30  0:47       ` Stefano Stabellini
2022-08-30  0:58         ` Henry Wang
2022-08-30  6:29           ` Michal Orzel
2022-08-30  7:10             ` Michal Orzel
2022-08-30  7:21               ` Henry Wang
2022-08-30  0:45   ` Stefano Stabellini
2022-08-30  1:02     ` Henry Wang
2022-09-01 14:36   ` Julien Grall
2022-09-02  1:28     ` Henry Wang
2022-09-02  8:01       ` Julien Grall
2022-09-02  8:21         ` Henry Wang
2022-08-24  7:31 ` [PATCH 2/2] xen/arm: Handle reserved heap pages in boot and heap allocator Henry Wang
2022-08-25 11:24   ` Michal Orzel
2022-08-30  6:11     ` Henry Wang
2022-08-30  7:19       ` Michal Orzel
2022-08-30  8:00         ` Henry Wang [this message]
2022-08-30  8:48           ` Michal Orzel
2022-08-30  9:17             ` Henry Wang
2022-08-30  9:48               ` Michal Orzel
2022-08-30 10:04                 ` Henry Wang
2022-08-30 17:28                   ` Stefano Stabellini
2022-08-31  1:36                     ` Henry Wang
2022-08-30 17:32           ` Stefano Stabellini
2022-09-01  1:03         ` Henry Wang
2022-09-01 13:31           ` Bertrand Marquis
2022-09-01 13:52             ` Henry Wang
2022-08-30  1:04   ` Stefano Stabellini
2022-08-30  8:27     ` Henry Wang
2022-08-30 17:25       ` Stefano Stabellini
2022-08-31  1:24         ` Henry Wang
2022-08-31  2:00           ` Henry Wang
2022-08-31 22:58           ` Stefano Stabellini
2022-09-01  0:49             ` Henry Wang
2022-09-01 13:58     ` Julien Grall
2022-09-01 14:01       ` Henry Wang
2022-09-01 14:02         ` Julien Grall
2022-09-01 15:29   ` Julien Grall
2022-09-01 16:05     ` Henry Wang
2022-09-01 17:08       ` Stefano Stabellini
2022-09-01 17:34         ` Julien Grall
2022-09-02  1:50           ` Stefano Stabellini
2022-09-02  3:02             ` Wei Chen
2022-09-02  3:07               ` Wei Chen
2022-09-02  8:04                 ` Julien Grall
2022-09-02  9:49                   ` Wei Chen
2022-09-01 17:19       ` Julien Grall
2022-09-02  3:30         ` Henry Wang
2022-09-02  8:11           ` Julien Grall
2022-09-02  8:18             ` Henry Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AS8PR08MB7991BB31E34ADB02069AE87292799@AS8PR08MB7991.eurprd08.prod.outlook.com \
    --to=henry.wang@arm.com \
    --cc=Bertrand.Marquis@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=Wei.Chen@arm.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.