Many machines fail to boot if this option is disabled, as
there are no known drawback toggling this option, enable it
by default.

Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
CC: Daniel P. Smith <dpsmith@apertussolutions.com>
CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

 xen/common/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index d7e79e752a..49dea2412d 100644
--- 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.
 
 config XSM
 	bool "Xen Security Modules support"
-- 
2.52.0



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

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.

> --- 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.

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

Jan

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@suse.com/
(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@citrix.com/

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

On Fri, Feb 06, 2026 at 12:52:18PM +0100, Marek Marczykowski-Górecki wrote:
> On Fri, Feb 06, 2026 at 07:29:49AM +0100, Jan Beulich wrote:
> > 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".

To be clear: I mean disabling the option (changing the new default)
should be IMHO hidden behind EXPERT.

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