Re: [Xen-devel] [PATCH v7 01/14] x86: move xen ELF end of image to 16 MiB

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.09.16 at 13:34, <daniel.kiper@xxxxxxxxxx> wrote:
> On Mon, Sep 26, 2016 at 04:39:37AM -0600, Jan Beulich wrote:
>> >>> On 23.09.16 at 23:47, <daniel.kiper@xxxxxxxxxx> wrote:
>> > It seems that from xen ELF image POV _end symbol properly determine
>> > image end. However, taking into account that initial Xen image mapping
>> > covers 16 MiB it looks that it is not sufficient. Currently bootloader
>> > potentially may load xen ELF image at 1 MiB and let's say put Linux
>> > kernel or initrd at 8 MiB. Nothing forbids it. This means that initially
>> > Xen image mapping may cover not only Xen image but also loaded modules.
>>
>> Okay, up to here you just describe the state of things, which is fine.
>>
>> > So, let's move end of xen ELF image to 16 MiB. This way we avoid above
>> > mentioned issue because bootloader will be forced to allocate 15 MiB
>> > memory region for image. Then it (bootloader) would not be able to put
>> > in this place anything else because from its POV simply this memory
>> > region will be allocated and used.
>>
>> But here you state what the patch does, but not what problem you
>> solve. And my problem here is that I don't see any problem to be
>> solved: There may be an overlap of address ranges, but I don't see
>> that memory being used in two different way. In fact the 16Mb
>> mapping is just a mapping, without us using anything outside the
>> Xen image range afaics.
> 
> However, this begs the question: Why do we map 16 MiB in Xen image address
> space if we do not expect anything sensible beyond the _end symbol?

Because it allows the page tables to be pre-populated at build time?

> Should
> not we stop just beyond the _end at 2 MiB boundary? This way if something
> accesses anything between _end and 16 MiB via Xen image mapping then way of
> failure is more predictable than now.

But that's not necessarily better - we might end up with an early
boot crash with a black screen.

> IIRC, this region (from _end to 16 MiB)
> is not even zeroed, so, unexpected things may happen.

As long as it doesn't get accessed I don't see what unpredictable
things you expect to happen.

Jan


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