Re: [Xen-devel] [PATCH v16 5/9] x86: change default load address from 1 MiB to 2 MiB

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Wed, Mar 01, 2017 at 04:21:35AM -0700, Jan Beulich wrote:
> >>> On 01.03.17 at 11:51, <daniel.kiper@xxxxxxxxxx> wrote:
> > On Wed, Mar 01, 2017 at 03:34:47AM -0700, Jan Beulich wrote:
> >> >>> On 01.03.17 at 11:13, <daniel.kiper@xxxxxxxxxx> wrote:
> >> > On Wed, Mar 01, 2017 at 02:05:39AM -0700, Jan Beulich wrote:
> >> >> >>> On 21.02.17 at 20:19, <daniel.kiper@xxxxxxxxxx> wrote:
> >> >> > Subsequent patches introducing relocatable early boot code play with
> >> >> > page tables using 2 MiB huge pages. If load address is not aligned at
> >> >> > 2 MiB then code touching such page tables must have special cases for
> >> >> > start and end of Xen image memory region. So, let's make life easier
> >> >> > and move default load address from 1 MiB to 2 MiB. This way page table
> >> >> > code will be nice and easy. Hence, there is a chance that it will be
> >> >> > less error prone too... :-)))
> >> >> >
> >> >> > Additionally, drop first 2 MiB mapping from Xen image mapping.
> >> >> > It is no longer needed.
> >> >>
> >> >> What about the memory allocated for it? Aiui at least in the xen.efi
> >> >> case there would be a 2Mb chunk left unused, but also never freed.
> >> >
> >> > Memory is not allocated for it.
> >>
> >> Are you sure? Where would the PE32+ header live in that case?
> >
> > Is the PE32+ header loaded into memory? I think that only code and data 
> > stuff
> > is put there. Header is useful only for loader. Am I missing something?
>
> I think EFI's loader simply follows Windows' one(s). And yes, the

Sadly, I do not know how Windows' one(s) work(s).

> headers can be useful - to the loader itself (albeit then the loader
> assumes that no-one fiddles with them).

I have looked at OVMF. It looks that OVMF loads PE32+ header aside, parses it, 
puts
Xen code and data into allocated memory (EfiLoaderCode type), does relocations 
and
jumps into entry point. So, more or less as I expected. It looks that it does 
not
load whole file at once. Hence, taking into account that memory allocated for 
Xen
image is marked as EfiLoaderCode it means that from Xen point of view this 
region
is free. Of course later everything between _start and _end is reserved. So, it
seems to me that everything between __image_base__ and _start is free and
available for Xen memory allocator. Am I missing something here?

Daniel

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