On Wed, Jul 19, 2017 at 4:08 PM, H. Peter Anvin <h...@zytor.com> wrote: > On 07/19/17 15:47, Thomas Garnier wrote: >> On Wed, Jul 19, 2017 at 3:33 PM, H. Peter Anvin <h...@zytor.com> wrote: >>> On 07/18/17 15:33, Thomas Garnier wrote: >>>> The x86 relocation tool generates a list of 32-bit signed integers. There >>>> was no need to use 64-bit integers because all addresses where above the 2G >>>> top of the memory. >>>> >>>> This change add a large-reloc option to generate 64-bit unsigned integers. >>>> It can be used when the kernel plan to go below the top 2G and 32-bit >>>> integers are not enough. >>> >>> Why on Earth? This would only be necessary if the *kernel itself* was >>> more than 2G, which isn't going to happen for the forseeable future. >> >> Because the relocation integer is an absolute address, not an offset >> in the binary. Next iteration, I can try using a 32-bit offset for >> everyone. > > It is an absolute address *as the kernel was originally linked*, for > obvious reasons.
Sure when the kernel was just above 0xffffffff80000000, it doesn't work when it goes down to 0xffffffff00000000. That's why using an offset might make more sense in general. > > -hpa > -- Thomas. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
