On 14.08.2024 23:31, Andrew Cooper wrote: > 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.
Which in turn so far was just to keep build machinery as uniform as possible. IOW I'd rather call the tags being there a side effect, not something that was intentional. And for MB1 I don't think that's going to change with the effort made now. Jan
