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