>>> On 30.08.16 at 18:35, <andrew.coop...@citrix.com> wrote: > On 19/08/16 13:57, Jan Beulich wrote: >>>>> On 19.08.16 at 14:39, <andrew.coop...@citrix.com> wrote: >>> On 19/08/16 08:52, Jan Beulich wrote: >>>> Page tables get pre-populated with physical addresses which, due to >>>> living inside the Xen image, will never exceed 32 bits in width. That >>>> in turn results in the tool generating the relocations to produce >>>> 32-bit relocations for them instead of the 64-bit ones needed for >>>> relocating virtual addresses. Hence instead of special casing page >>>> tables in the processing of 64-bit relocations, let's be more rigid >>>> and refuse them (as being indicative of something else having gone >>>> wrong in the build process). >>>> >>>> Signed-off-by: Jan Beulich <jbeul...@suse.com> >>> Is it an ABI requirement to use the minimal available relocation? It is >>> certainly suboptimal to use a 64bit relocation when a 32bit one would >>> do, but I wouldn't bet that it is unconditional avoided by all toolchains. >> What ABI? The tool in question is one of our own making. And the >> way relocations get generated it's hard to tell those that have to >> be 32-bit (in early boot code and trampoline code) from those that >> may as well be 64-bit ones (in page tables). >> >>> It is currently the case that Xen needs to live below 4GB physical, so >>> from that point of view a 64bit relocation will not be required in the >>> pagetables. >> And even if Xen didn't itself have this requirement, the EFI loader >> would always put us below 4Gb. > > Why is this necessarily true? > > xen.efi is built as a 64bit PE, not 32bit.
The file format doesn't matter here. And we'd have other problems to solve if we got loaded above 4Gb. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
