Re: [Xen-devel] [PATCH v6 01/15] x86: properly calculate ELF end of image address

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.09.16 at 13:43, <daniel.kiper@xxxxxxxxxx> wrote:
> On Mon, Sep 19, 2016 at 08:52:02AM -0600, Jan Beulich wrote:
>> >>> On 19.09.16 at 15:56, <daniel.kiper@xxxxxxxxxx> wrote:
>> > On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote:
>> >> >>> On 16.09.16 at 22:43, <konrad.wilk@xxxxxxxxxx> wrote:
>> >> > On Mon, Sep 12, 2016 at 10:18:16PM +0200, Daniel Kiper wrote:
>> >> In particular
>> >> I can't see why __2M_rwdata_end (aliased to efi) does not relate to
>> >> the intended image end. Once we switch back to using large pages
>> >> even when not using xen.efi I'd even question whether preferring
>> >> _end over __2M_rwdata_end is actually correct.
>> >
>> > This is good question. I was thinking about that after posting v6. It seems
>> > that from image POV _end is correct. However, taking into account that Xen
>> > image mapping covers 16 MiB then I think we should use __2M_rwdata_end (or
>> > define __end_of_image__ symbol equal to __2M_rwdata_end). This way boot
>> > loader will allocate memory region for Xen image later covered properly by
>> > mapping, nothing will be put in memory immediately after the Xen image and
>> > later incorrectly mapped as Xen image.
> 
> Current xen image p_memsz does not end at 16 MiB. It seems to me that this is
> incorrect. Should I fix it? It looks that we just have to move out .pad of
> #ifdef EFI. Are you OK with it?

Just to emphasize again: I'm okay with any fix which actually fixes
something. I continue to be unconvinced there is something that
actually needs fixing. So as long as you can properly explain what
is wrong, I won't stand in the way of your change going in. For the
case here this means - if the value is e.g. off by a few bytes, then
I don't see an issue. This 16Mb boundary isn't a hard one anyway.
If otoh the value is off by an arbitrary amount, which just happens
to be small enough in most cases, then I do see a need for a change.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel