Re: [Xen-devel] [PATCH] EFI: add efi=mapbs option and parse efi= early

[Jan Beulich <JBeulich@xxxxxxxx>]

On 08.08.2019 11:40, Andrew Cooper wrote:
> On 08/08/2019 01:31, Marek Marczykowski-Górecki wrote:
>> When booting Xen via xen.efi, there is /mapbs option to workaround
>> certain platform issues (added in f36886bdf4 "EFI/early: add /mapbs to
>> map EfiBootServices{Code,Data}"). Add support for efi=mapbs on Xen
>> cmdline for the same effect and parse it very early in the
>> multiboot2+EFI boot path.
>>
>> Normally cmdline is parsed after relocating MB2 structure, which happens
>> too late. To have efi= parsed early enough, save cmdline pointer in
>> head.S and pass it as yet another argument to efi_multiboot2(). This
>> way we avoid introducing yet another MB2 structure parser.
>>
>> To keep consistency, handle efi= parameter early in xen.efi too, both in
>> xen.efi command line and cfg file.
>>
>> Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> 
> I'm very sorry to do this to you, but I'm going to object to the patch
> (in principle.  I think the command line option itself is fine but...)
> 
> What does Linux do differently here?
> 
> It is actively damaging to the Xen community to users to force users
> tweak command lines in order to boot/recover their system, and it looks
> especially embarrassing when other OSes cope automatically.  We have
> compatibility for all kinds of other firmware screw-ups, except EFI it
> seems, and this needs to change.
> 
> So while I have no objection to the option per say, I don't think this
> patch is reasonable as a "fix" to the problem as far as end users are
> concerned.

And your suggestion then is to always map (and not use) all boot
services memory, contrary to all intentions of the EFI spec?

As to your more general rant: I think it is wrong to have more
than very simple and low overhead workarounds enabled "just in
case". The vast majority of the workarounds we have in place
are keyed to specific versions of something, or e.g. DMI
properties of systems. I certainly wouldn't mind DMI based
enabling of workarounds like the one here, but I'm going to
continue to push back on attempts to cripple the EFI code just
because _some_ systems don't have a sensible EFI implementation.

Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel