On 14/08/2024 9:34 am, Frediano Ziglio wrote: > Testing this feature in preparation for UEFI CA memory mitigation > requirements I found some issues causing the loading to fail and > other minor issues. > Details in series commit messages. > This is adding an additional way to boot Xen, using GrUB2+EFI > (xen.efi:__efi64_mb2_start). > > Changes since v1: > - Changed title, apparently this is a kind of new mode; > - address lot of comments (see "Changes" in other messages). > > Frediano Ziglio (5): > x86: Put trampoline in .init.data section > x86: Set xen_phys_start and trampoline_xen_phys_start earlier > x86: Force proper gdt_boot_base setting > x86: Compensate relocation in case of EFI > x86: Rollback relocation in case of EFI multiboot
Patch 1 is one part of supporting NX_COMPAT in the PE header, which is a requirement from Microsoft in order to be signed. It has nothing to do with the rest of the series, which is about making the EFI+MB2 entry point work. It would have helped a lot to not have mixed these together in a series claiming to only be about the latter. Now, as indicated in our documentation (yes - this is one of the very few I have managed to get committed), https://xenbits.xen.org/docs/latest/hypervisor-guide/x86/how-xen-boots.html#xen-efi The MB2 tags existing in xen.efi is a known thing but came as a surprise to some. It exists because xen.efi is a strict superset of xen.gz, including head.S which contains the MB1/MB2 tags. Nevertheless, if we want to make EFI+MB2 work, that's fine, but the final patch in the series needs to be one updating the docs to reflect the new behaviour of Xen. ~Andrew
