Re: [PATCH v2 0/5] Support EFI multiboot loading using PE binary

[Jan Beulich <jbeulich@xxxxxxxx>]

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