[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 8/8] efi: drop original xen.efi code and build mechanism
>>> On 04.07.18 at 16:25, <daniel.kiper@xxxxxxxxxx> wrote: > On Thu, Jun 28, 2018 at 07:51:52AM -0600, Jan Beulich wrote: >> >>> On 19.06.18 at 16:35, <daniel.kiper@xxxxxxxxxx> wrote: >> > Then rename xen.mb.efi to xen.efi and drop all related >> > differentiators in the code. >> >> For this you'll first of all need to convince me that the binary you build is >> a drop-in replacement for xen.efi. As noted in the replies to earlier >> patches, I'm getting the impression of this not being the case. A further >> hint towards this is the outright deletion of xen/arch/x86/efi/mkreloc.c: >> How is the Xen image going to be relocated that way, when loaded from >> the EFI shell or boot loader? > > It works because all addressing is relative to %rip. To be precise, new > xen.efi, earlier xen.mb.efi, contains exactly the same code as ELF does. > So, if ELF works without any relocations why PE should not. Especially on > x86-64. Additionally, my tests showed that in general UEFI implementations > just require Base Relocation Table entry in PE Data Directories to relocate > the image. The thing I'm missing in the series is the generation of the relocations to go into the section pointed to by this Data Directory entry. > Even it can be empty. As it is in current patchset. No, it can't be empty. Just try removing the relocations from xen.efi and see what you get. > Though I am > afraid about more picky UEFI stuff and considering addition of at least > one .reloc entry, fake one, as Linux kernel does. And this rises another > question: should not we add .bss section into PE header? Right now it is > embedded/hidden in PE .text section. My xen.efi does have a .bss section. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |