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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.03.17 at 15:51, <daniel.kiper@xxxxxxxxxx> wrote:
> 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?

Oh, right, the EFI memory type is what removes the need to free
anything here. I'm sorry for the noise.

Jan


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