From: Brian Woods <brian.woods@xilinx.com>
To: Julien Grall <julien.grall@arm.com>
Cc: Brian Woods <brian.woods@xilinx.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen/arm: add warning if memory modules overlap
Date: Thu, 17 Oct 2019 12:48:53 -0700 [thread overview]
Message-ID: <20191017194853.GB6184@xilinx.com> (raw)
In-Reply-To: <729fbca8-9a9c-8764-9f9d-c24140d9bb68@arm.com>
On Thu, Oct 17, 2019 at 10:20:11AM +0100, Julien Grall wrote:
> Hi,
>
> Sorry for the late answer.
>
> On 11/10/2019 20:07, Brian Woods wrote:
> >Which is why I wanted to put it where it was in the patch. Where the
> >user would see the warning after the information about the memory
> >modules were printed (and fair early).
>
> I had a think about it, dumping the modules informations before is useful if
> you know that you have one module max per kind. So you avoid to print the
> modules address/size in the warning.
>
> However, it is possible to have multiple kernel module (as long as they
> don't have the same start address), you could end up with the following
> message:
>
> "WARNING: modules Kernel and Kernel overlap"
>
> To make the message more meaningful, we would need to print the modules
> address/size. Therefore, I don't view that it is important to check
> overlapping in early_print_info(). In this case I would favor any code that
> don't add a double for loop.
Well, adding that information would be easy enough and cheap. It would
make it multiline prinktk though:
WARNING: memory modules over lap:
start_addr-end_addr: modulename
start_addr-end_addr: modulename
If we're not doing that though, would it make sense to have a initdata
bool that checks it in add_boot_module() and then prints a simple
warning that there's a memory module overlap in early_print_info()?
That way there's no nested for loop and it gets printed where all the
addresses get printed (so you can actually figure out where the overlap
is).
> While thinking about this case, it made me realize that we only check the
> start address to consider a match. This means if the size is different, then
> it will be ignored. I think we ought to throw at least warning for this case
> as well.
>
> Would you mind to have a look?
When you say starting address, do you mean like in the orginal patch?
If so, there's no functional change in checking the starts of n on m and
m on n then checking the start and end of n on m.
> >
> >Either way, take your pick of location and if it's only debug or not and
> >I can write it up and test it.
>
> I would still prefer in add_boot_module(). See why above.
I wrote I suggested above and tested it so that'll be sent out soon.
Brian
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-10-17 19:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-09 19:47 [Xen-devel] [PATCH] xen/arm: add warning if memory modules overlap Brian Woods
2019-10-10 15:39 ` Julien Grall
2019-10-11 16:43 ` Brian Woods
2019-10-11 16:58 ` Julien Grall
2019-10-11 18:06 ` Brian Woods
2019-10-11 18:17 ` Julien Grall
2019-10-11 19:07 ` Brian Woods
2019-10-17 9:20 ` Julien Grall
2019-10-17 19:48 ` Brian Woods [this message]
2019-10-17 20:23 ` Julien Grall
2019-10-17 20:07 ` [Xen-devel] [PATCH v2] " Brian Woods
2019-10-17 20:34 ` Julien Grall
2019-10-17 21:20 ` Brian Woods
2019-10-17 21:49 ` Julien Grall
2019-10-17 22:34 ` Brian Woods
2019-10-18 15:41 ` Julien Grall
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=20191017194853.GB6184@xilinx.com \
--to=brian.woods@xilinx.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=julien.grall@arm.com \
--cc=julien@xen.org \
--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.