Re: [PATCH] efi: Enable EFI_SET_VIRTUAL_ADDRESS_MAP by default

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Feb 06, 2026 at 07:29:49AM +0100, Jan Beulich wrote:
> On 05.02.2026 18:27, Teddy Astie wrote:
> > Many machines fail to boot if this option is disabled, as
> > there are no known drawback toggling this option, enable it
> > by default.
> 
> "no known drawback" ignores why it wasn't enabled originally. Imo this
> wants at least mentioning, if not discussing.

Relevant discussion was at 
https://lore.kernel.org/xen-devel/4e46a667-da69-9f25-387e-4dd45db10cda@xxxxxxxx/
(previous attempt at switching the default)

And also, (large) part of the reason for this being off by default
initially was it being close to 4.13 release:
https://lore.kernel.org/xen-devel/272a9354-bcb4-50a4-a251-6a453221d6e3@xxxxxxxxxx/

Now it's substantially earlier in the 4.22 release cycle.

But yes, some note in patch description would be nice.

> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -363,13 +363,14 @@ config KEXEC
> >  
> >  config EFI_SET_VIRTUAL_ADDRESS_MAP
> >      bool "EFI: call SetVirtualAddressMap()" if EXPERT
> > +    default y
> >      help
> >        Call EFI SetVirtualAddressMap() runtime service to setup memory map 
> > for
> >        further runtime services. According to UEFI spec, it isn't strictly
> >        necessary, but many UEFI implementations misbehave when this call is
> >        missing.
> >  
> > -      If unsure, say N.
> > +      If unsure, say Y.
> 
> When this was added, it was actually hacked in with the aim of minimal
> intrusiveness. When we now default it to on, I wonder if other changes
> shouldn't be made (maybe not right in this patch, but perhaps in a
> single series). For example, identity mapping (with its implied
> restrictions) ought to be possible to do away with when the option is
> enabled. Whether the separate EFI page tables would still be needed
> also is questionable.

This is an interesting question, but IMHO the current approach is safer
(or rather: more reliable) - which is relevant given how many UEFI
systems are not exactly spec compliant...
One approach that could be tried is to mirror what Linux does, but I
don't see it as necessary for flipping the default. And in fact I would
rather prefer to not do that at the same time - the current approach is
battle tested by several downstream projects on a large number of
systems.

> I further wonder whether the EXPERT dependency of the prompt wouldn't
> better be dropped when flipping the default.

IMO the EXPERT dependency is still relevant. This option is basically
"break Xen on a large number of UEFI systems".

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature