[PATCH] hv: add CONFIG_EFI dependency

[PATCH] hv: add CONFIG_EFI dependency

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

Selecting SYSFB causes a link failure on arm64 kernels with EFI disabled:

ld.lld-21: error: undefined symbol: screen_info
>>> referenced by sysfb.c
>>>               drivers/firmware/sysfb.o:(sysfb_parent_dev) in archive vmlinux.a
>>> referenced by sysfb.c

The problem is that sysfb works on the global 'screen_info' structure, which
is provided by the firmware interface, either the generic EFI code or the
x86 BIOS startup.

Assuming that HV always boots Linux using UEFI, the dependency also makes
logical sense, since otherwise it is impossible to boot a guest.

Fixes: 96959283a58d ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/hv/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 8622d0733723..07db5e9a00f9 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -6,6 +6,7 @@ config HYPERV
 	tristate "Microsoft Hyper-V client drivers"
 	depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
 		|| (ARM64 && !CPU_BIG_ENDIAN && HAVE_ARM_SMCCC_DISCOVERY)
+	depends on EFI
 	select PARAVIRT
 	select X86_HV_CALLBACK_VECTOR if X86
 	select OF_EARLY_FLATTREE if OF
-- 
2.39.5

[PATCH] hv: add CONFIG_EFI dependency

[Roman Kisel]

> Selecting SYSFB causes a link failure on arm64 kernels with EFI disabled:
>
> ld.lld-21: error: undefined symbol: screen_info
> >>> referenced by sysfb.c
> >>>               drivers/firmware/sysfb.o:(sysfb_parent_dev) in archive vmlinux.a
> >>> referenced by sysfb.c
>
> The problem is that sysfb works on the global 'screen_info' structure, which
> is provided by the firmware interface, either the generic EFI code or the
> x86 BIOS startup.
>
> Assuming that HV always boots Linux using UEFI, the dependency also makes
> logical sense, since otherwise it is impossible to boot a guest.
>

Hyper-V as of recent can boot off DeviceTree with the direct kernel boot, no UEFI
is required (examples would be OpenVMM and the OpenHCL paravisor on arm64).

Being no expert in Kconfig unfortunately... If another solution is possible to
find given the timing constraints (link errors can't wait iiuc) that would be
great :)

Could something like "select EFI if SYSFB" work?

> Fixes: 96959283a58d ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/hv/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 8622d0733723..07db5e9a00f9 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -6,6 +6,7 @@ config HYPERV
>  	tristate "Microsoft Hyper-V client drivers"
>  	depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
>  		|| (ARM64 && !CPU_BIG_ENDIAN && HAVE_ARM_SMCCC_DISCOVERY)
> +	depends on EFI
>  	select PARAVIRT
>  	select X86_HV_CALLBACK_VECTOR if X86
>  	select OF_EARLY_FLATTREE if OF
> --
> 2.39.5

Re: [PATCH] hv: add CONFIG_EFI dependency

[Arnd Bergmann]

On Tue, Jun 10, 2025, at 17:33, Roman Kisel wrote:
>> Selecting SYSFB causes a link failure on arm64 kernels with EFI disabled:
>>
>> ld.lld-21: error: undefined symbol: screen_info
>> >>> referenced by sysfb.c
>> >>>               drivers/firmware/sysfb.o:(sysfb_parent_dev) in archive vmlinux.a
>> >>> referenced by sysfb.c
>>
>> The problem is that sysfb works on the global 'screen_info' structure, which
>> is provided by the firmware interface, either the generic EFI code or the
>> x86 BIOS startup.
>>
>> Assuming that HV always boots Linux using UEFI, the dependency also makes
>> logical sense, since otherwise it is impossible to boot a guest.
>>
>
> Hyper-V as of recent can boot off DeviceTree with the direct kernel 
> boot, no UEFI
> is required (examples would be OpenVMM and the OpenHCL paravisor on 
> arm64).

I was aware of hyperv no longer needing ACPI, but devicetree and UEFI
are orthogonal concepts, and I had expected that even the devicetree
based version would still get booted using a tiny UEFI implementation
even if the kernel doesn't need that. Do you know what type of bootloader
is actually used in the examples you mentioned? Does the hypervisor
just start the kernel at the native entry point without a bootloader
in this case?

> Being no expert in Kconfig unfortunately... If another solution is possible to
> find given the timing constraints (link errors can't wait iiuc) that would be
> great :)
>
> Could something like "select EFI if SYSFB" work?

You probably mean the reverse here:

      select SYSFB if EFI && !HYPERV_VTL_MODE

I think that should work, as long as the change from the 96959283a58d
("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests") patch
is not required in the cases where the guest has no bootloader.

Possibly this would also work

     select SYSFB if X86 && !HYPERV_VTL_MODE

in case only the x86 host requires the sysfb hack, but arm can
rely on PCI device probing instead.

Or perhaps this version

--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -19,6 +19,7 @@ config HYPERV_VTL_MODE
        bool "Enable Linux to boot in VTL context"
        depends on (X86_64 || ARM64) && HYPERV
        depends on SMP
+       depends on !EFI
        default n
        help
          Virtual Secure Mode (VSM) is a set of hypervisor capabilities and

if the VTL mode is never used with a boot loader in the guest.

     Arnd

RE: [PATCH] hv: add CONFIG_EFI dependency

[Michael Kelley]

From: Arnd Bergmann <arnd@arndb.de> Sent: Tuesday, June 10, 2025 8:46 AM
> 
> On Tue, Jun 10, 2025, at 17:33, Roman Kisel wrote:
> >> Selecting SYSFB causes a link failure on arm64 kernels with EFI disabled:
> >>
> >> ld.lld-21: error: undefined symbol: screen_info
> >> >>> referenced by sysfb.c
> >> >>>               drivers/firmware/sysfb.o:(sysfb_parent_dev) in archive vmlinux.a
> >> >>> referenced by sysfb.c
> >>
> >> The problem is that sysfb works on the global 'screen_info' structure, which
> >> is provided by the firmware interface, either the generic EFI code or the
> >> x86 BIOS startup.
> >>
> >> Assuming that HV always boots Linux using UEFI, the dependency also makes
> >> logical sense, since otherwise it is impossible to boot a guest.

This problem was flagged by the kernel test robot over the weekend [1], and I
Had been thinking about the best solution.

Just curious -- do you have real builds that have CONFIG_HYPERV=y (or =m)
and CONFIG_EFI=n? I had expected that to be a somewhat nonsense config,
but maybe not.

Hyper-V supports what it calls "Generation 1" and "Generation 2" guest VMs.
Generation 1 guests boot from BIOS, while Generation 2 guests boot from UEFI. 
x86/x64 can be either generation, while ARM64 is Generation 2 only. Furthermore,
the VTL2 paravisor is supported only in Generation 2 VMs. But I'm not clear on
what dependencies on EFI the VTL2 paravisor might have, if any. Roman -- are
VTL2 paravisors built with CONFIG_EFI=n?

> >>
> >
> > Hyper-V as of recent can boot off DeviceTree with the direct kernel  boot, no UEFI
> > is required (examples would be OpenVMM and the OpenHCL paravisor on arm64).
> 
> I was aware of hyperv no longer needing ACPI, but devicetree and UEFI
> are orthogonal concepts, and I had expected that even the devicetree
> based version would still get booted using a tiny UEFI implementation
> even if the kernel doesn't need that. Do you know what type of bootloader
> is actually used in the examples you mentioned? Does the hypervisor
> just start the kernel at the native entry point without a bootloader
> in this case?

Need Roman to clarify this.

> 
> > Being no expert in Kconfig unfortunately... If another solution is possible to
> > find given the timing constraints (link errors can't wait iiuc) that would be
> > great :)
> >
> > Could something like "select EFI if SYSFB" work?
> 
> You probably mean the reverse here:
> 
>       select SYSFB if EFI && !HYPERV_VTL_MODE

Yes, this is one approach I was thinking about. However, this problem
exposed the somewhat broader topic that at least for ARM64 normal
VMs, CONFIG_HYPERV really does have a dependency on EFI, and that
dependency isn't expressed anywhere. For x86/x64, I want to run some
experiments to be sure a Generation 1 VM really will build and boot
with CONFIG_EFI=n. Then if we can do so, I'd rather add the correct
broader dependency on EFI than embedding the dependency just in
the SYSFB selection.

> 
> I think that should work, as long as the change from the 96959283a58d
> ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests") patch
> is not required in the cases where the guest has no bootloader.

Yes, I think this is true.

> 
> Possibly this would also work
> 
>      select SYSFB if X86 && !HYPERV_VTL_MODE
> 
> in case only the x86 host requires the sysfb hack, but arm can
> rely on PCI device probing instead.

This doesn't work. Regular ARM64 guests require the sysfb hack
as well.

> 
> Or perhaps this version
> 
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -19,6 +19,7 @@ config HYPERV_VTL_MODE
>         bool "Enable Linux to boot in VTL context"
>         depends on (X86_64 || ARM64) && HYPERV
>         depends on SMP
> +       depends on !EFI
>         default n
>         help
>           Virtual Secure Mode (VSM) is a set of hypervisor capabilities and
> 
> if the VTL mode is never used with a boot loader in the guest.
> 
>      Arnd

[1] https://lore.kernel.org/lkml/202506080820.1wmkQufc-lkp@intel.com/

RE: [PATCH] hv: add CONFIG_EFI dependency

[Roman Kisel]

> On Tue, Jun 10, 2025, at 17:33, Roman Kisel wrote:
>>> Selecting SYSFB causes a link failure on arm64 kernels with EFI disabled:
>>>
>>> ld.lld-21: error: undefined symbol: screen_info
>>>>>> referenced by sysfb.c
>>>>>>               drivers/firmware/sysfb.o:(sysfb_parent_dev) in archive vmlinux.a
>>>>>> referenced by sysfb.c
>>>
>>> The problem is that sysfb works on the global 'screen_info' structure, which
>>> is provided by the firmware interface, either the generic EFI code or the
>>> x86 BIOS startup.
>>>
>>> Assuming that HV always boots Linux using UEFI, the dependency also makes
>>> logical sense, since otherwise it is impossible to boot a guest.
>>>
>>
>> Hyper-V as of recent can boot off DeviceTree with the direct kernel
>> boot, no UEFI
>> is required (examples would be OpenVMM and the OpenHCL paravisor on
>> arm64).
>
> I was aware of hyperv no longer needing ACPI, but devicetree and UEFI
> are orthogonal concepts, and I had expected that even the devicetree
> based version would still get booted using a tiny UEFI implementation
> even if the kernel doesn't need that. Do you know what type of bootloader
> is actually used in the examples you mentioned? Does the hypervisor
> just start the kernel at the native entry point without a bootloader
> in this case?

The kernel is started at the native entry point in "Image", and the address of
the DeviceTree blob is passed in X0.

There is a "virtual baremetal" bootloader [1] that prepares DeviceTree for the
kernel, sets some CPU registers and jumps to the Image's entry point yet that's
totally headless except for the optional serial output. No ACPI or UEFI is involved
at all.

>
>> Being no expert in Kconfig unfortunately... If another solution is possible to
>> find given the timing constraints (link errors can't wait iiuc) that would be
>> great :)
>>
>> Could something like "select EFI if SYSFB" work?
>
> You probably mean the reverse here:
>
>       select SYSFB if EFI && !HYPERV_VTL_MODE
>

Right :)

> I think that should work, as long as the change from the 96959283a58d
> ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests") patch
> is not required in the cases where the guest has no bootloader.
>

That would be awesome!! I can't see the pro's and con's to arrive at the perfect
solution quickly enough and am mostly driven by the sense that unconditional
EFI seems superfluous. Again, I do understand that the build is broken, and
something that fixes it fast should be the best solution.

> Possibly this would also work
>
>      select SYSFB if X86 && !HYPERV_VTL_MODE
>
> in case only the x86 host requires the sysfb hack, but arm can
> rely on PCI device probing instead.
>
> Or perhaps this version
>
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -19,6 +19,7 @@ config HYPERV_VTL_MODE
>         bool "Enable Linux to boot in VTL context"
>         depends on (X86_64 || ARM64) && HYPERV
>         depends on SMP
> +       depends on !EFI
>         default n
>         help
>           Virtual Secure Mode (VSM) is a set of hypervisor capabilities and
>
> if the VTL mode is never used with a boot loader in the guest.

The VTL mode uses the direct kernel boot and a DeviceTree blob, doesn't
need ACPI and UEFI.

[1]
https://github.com/microsoft/openvmm/tree/main/openhcl/openhcl_boot

>
>      Arnd

--
Thank you,
Roman

RE: [PATCH] hv: add CONFIG_EFI dependency

[Roman Kisel]

>the VTL2 paravisor is supported only in Generation 2 VMs. But I'm not clear on
>what dependencies on EFI the VTL2 paravisor might have, if any. Roman -- are
>VTL2 paravisors built with CONFIG_EFI=n?

Thank you, Michael, for your help! We disable EFI:
* https://github.com/microsoft/OHCL-Linux-Kernel/blob/product/hcl-main/6.12/Microsoft/hcl-arm64.config
* https://github.com/microsoft/OHCL-Linux-Kernel/blob/product/hcl-main/6.12/Microsoft/hcl-x4.config

>
>> >>
>> >
>> > Hyper-V as of recent can boot off DeviceTree with the direct kernel  boot, no UEFI
>> > is required (examples would be OpenVMM and the OpenHCL paravisor on arm64).
>> 
>> I was aware of hyperv no longer needing ACPI, but devicetree and UEFI
>> are orthogonal concepts, and I had expected that even the devicetree
>> based version would still get booted using a tiny UEFI implementation
>> even if the kernel doesn't need that. Do you know what type of bootloader
>> is actually used in the examples you mentioned? Does the hypervisor
>> just start the kernel at the native entry point without a bootloader
>> in this case?
>
>Need Roman to clarify this.
>

The kernel is started at the native entry point in "Image", and the address of
the DeviceTree blob is passed in X0.

There is a "virtual baremetal" bootloader [1] that prepares DeviceTree for the
kernel, sets some CPU registers and jumps to the Image's entry point yet that's
totally headless except for the optional serial output. No ACPI or UEFI is involved
at all. For all intents and purposes, that's the kernel direct boot :)

[1]
https://github.com/microsoft/openvmm/tree/main/openhcl/openhcl_boot

RE: [PATCH] hv: add CONFIG_EFI dependency

[Michael Kelley]

From: Michael Kelley <mhklinux@outlook.com> Sent: Tuesday, June 10, 2025 9:17 AM
> 
> From: Arnd Bergmann <arnd@arndb.de> Sent: Tuesday, June 10, 2025 8:46 AM
> >
> > On Tue, Jun 10, 2025, at 17:33, Roman Kisel wrote:
> > >> Selecting SYSFB causes a link failure on arm64 kernels with EFI disabled:
> > >>
> > >> ld.lld-21: error: undefined symbol: screen_info
> > >> >>> referenced by sysfb.c
> > >> >>>               drivers/firmware/sysfb.o:(sysfb_parent_dev) in archive vmlinux.a
> > >> >>> referenced by sysfb.c
> > >>
> > >> The problem is that sysfb works on the global 'screen_info' structure, which
> > >> is provided by the firmware interface, either the generic EFI code or the
> > >> x86 BIOS startup.
> > >>
> > >> Assuming that HV always boots Linux using UEFI, the dependency also makes
> > >> logical sense, since otherwise it is impossible to boot a guest.
> 
> This problem was flagged by the kernel test robot over the weekend [1], and I
> Had been thinking about the best solution.
> 
> Just curious -- do you have real builds that have CONFIG_HYPERV=y (or =m)
> and CONFIG_EFI=n? I had expected that to be a somewhat nonsense config,
> but maybe not.
> 
> Hyper-V supports what it calls "Generation 1" and "Generation 2" guest VMs.
> Generation 1 guests boot from BIOS, while Generation 2 guests boot from UEFI.
> x86/x64 can be either generation, while ARM64 is Generation 2 only. Furthermore,
> the VTL2 paravisor is supported only in Generation 2 VMs. But I'm not clear on
> what dependencies on EFI the VTL2 paravisor might have, if any. Roman -- are
> VTL2 paravisors built with CONFIG_EFI=n?
> 
> > >>
> > >
> > > Hyper-V as of recent can boot off DeviceTree with the direct kernel  boot, no UEFI
> > > is required (examples would be OpenVMM and the OpenHCL paravisor on arm64).
> >
> > I was aware of hyperv no longer needing ACPI, but devicetree and UEFI
> > are orthogonal concepts, and I had expected that even the devicetree
> > based version would still get booted using a tiny UEFI implementation
> > even if the kernel doesn't need that. Do you know what type of bootloader
> > is actually used in the examples you mentioned? Does the hypervisor
> > just start the kernel at the native entry point without a bootloader
> > in this case?
> 
> Need Roman to clarify this.
> 
> >
> > > Being no expert in Kconfig unfortunately... If another solution is possible to
> > > find given the timing constraints (link errors can't wait iiuc) that would be
> > > great :)
> > >
> > > Could something like "select EFI if SYSFB" work?
> >
> > You probably mean the reverse here:
> >
> >       select SYSFB if EFI && !HYPERV_VTL_MODE
> 
> Yes, this is one approach I was thinking about. However, this problem
> exposed the somewhat broader topic that at least for ARM64 normal
> VMs, CONFIG_HYPERV really does have a dependency on EFI, and that
> dependency isn't expressed anywhere. For x86/x64, I want to run some
> experiments to be sure a Generation 1 VM really will build and boot
> with CONFIG_EFI=n. Then if we can do so, I'd rather add the correct
> broader dependency on EFI than embedding the dependency just in
> the SYSFB selection.

I've built and tested x86/x64 Generation 1 VMs with CONFIG_EFI=n,
and I don't see any problems. No build-time EFI dependencies have
accidently crept into the Gen1 code paths over the years. Since
Roman has confirmed that VTL2 images do not use EFI, we could
express CONFIG_HYPERV's broader dependency on EFI as:

     depends on EFI if ARM64 && !HYPERV_VTL_MODE

which would allow building an image without EFI for an x86/x64
Generation 1 VM. The newly added "select SYSFB" entry would do the
right thing and stay unchanged.

An alternate viewpoint is that we've always built Hyper-V x86/x64
guest images to be portable between Generation 1 or Generation 2
VMs, and that allowing x86/x64 images with CONFIG_EFI=n for Gen 1
VMs only isn't necessary. In that case we could just add

   depends on EFI if !HYPERV_VTL_MODE

I lean slightly toward the first of the two, and not requiring EFI on
x86/x64 if someone really wanted to build an image that only runs
on Gen 1 VMs. But the downside is that someone who built such an
image might be surprised it won't run on a Gen 2 VM. Anyone at
Microsoft want to weigh in on the choice?

Michael

> 
> >
> > I think that should work, as long as the change from the 96959283a58d
> > ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests") patch
> > is not required in the cases where the guest has no bootloader.
> 
> Yes, I think this is true.
> 
> >
> > Possibly this would also work
> >
> >      select SYSFB if X86 && !HYPERV_VTL_MODE
> >
> > in case only the x86 host requires the sysfb hack, but arm can
> > rely on PCI device probing instead.
> 
> This doesn't work. Regular ARM64 guests require the sysfb hack
> as well.
> 
> >
> > Or perhaps this version
> >
> > --- a/drivers/hv/Kconfig
> > +++ b/drivers/hv/Kconfig
> > @@ -19,6 +19,7 @@ config HYPERV_VTL_MODE
> >         bool "Enable Linux to boot in VTL context"
> >         depends on (X86_64 || ARM64) && HYPERV
> >         depends on SMP
> > +       depends on !EFI
> >         default n
> >         help
> >           Virtual Secure Mode (VSM) is a set of hypervisor capabilities and
> >
> > if the VTL mode is never used with a boot loader in the guest.
> >
> >      Arnd
> 
> [1] https://lore.kernel.org/lkml/202506080820.1wmkQufc-lkp@intel.com/

RE: [PATCH] hv: add CONFIG_EFI dependency

[Michael Kelley]

From: Michael Kelley <mhklinux@outlook.com> Sent: Tuesday, June 10, 2025 11:46 AM
> 
> From: Michael Kelley <mhklinux@outlook.com> Sent: Tuesday, June 10, 2025 9:17 AM
> >
> > From: Arnd Bergmann <arnd@arndb.de> Sent: Tuesday, June 10, 2025 8:46 AM
> > >
> > > On Tue, Jun 10, 2025, at 17:33, Roman Kisel wrote:
> > > >> Selecting SYSFB causes a link failure on arm64 kernels with EFI disabled:
> > > >>
> > > >> ld.lld-21: error: undefined symbol: screen_info
> > > >> >>> referenced by sysfb.c
> > > >> >>>               drivers/firmware/sysfb.o:(sysfb_parent_dev) in archive vmlinux.a
> > > >> >>> referenced by sysfb.c
> > > >>
> > > >> The problem is that sysfb works on the global 'screen_info' structure, which
> > > >> is provided by the firmware interface, either the generic EFI code or the
> > > >> x86 BIOS startup.
> > > >>
> > > >> Assuming that HV always boots Linux using UEFI, the dependency also makes
> > > >> logical sense, since otherwise it is impossible to boot a guest.
> >
> > This problem was flagged by the kernel test robot over the weekend [1], and I
> > Had been thinking about the best solution.
> >
> > Just curious -- do you have real builds that have CONFIG_HYPERV=y (or =m)
> > and CONFIG_EFI=n? I had expected that to be a somewhat nonsense config,
> > but maybe not.
> >
> > Hyper-V supports what it calls "Generation 1" and "Generation 2" guest VMs.
> > Generation 1 guests boot from BIOS, while Generation 2 guests boot from UEFI.
> > x86/x64 can be either generation, while ARM64 is Generation 2 only. Furthermore,
> > the VTL2 paravisor is supported only in Generation 2 VMs. But I'm not clear on
> > what dependencies on EFI the VTL2 paravisor might have, if any. Roman -- are
> > VTL2 paravisors built with CONFIG_EFI=n?
> >
> > > >>
> > > >
> > > > Hyper-V as of recent can boot off DeviceTree with the direct kernel  boot, no UEFI
> > > > is required (examples would be OpenVMM and the OpenHCL paravisor on arm64).
> > >
> > > I was aware of hyperv no longer needing ACPI, but devicetree and UEFI
> > > are orthogonal concepts, and I had expected that even the devicetree
> > > based version would still get booted using a tiny UEFI implementation
> > > even if the kernel doesn't need that. Do you know what type of bootloader
> > > is actually used in the examples you mentioned? Does the hypervisor
> > > just start the kernel at the native entry point without a bootloader
> > > in this case?
> >
> > Need Roman to clarify this.
> >
> > >
> > > > Being no expert in Kconfig unfortunately... If another solution is possible to
> > > > find given the timing constraints (link errors can't wait iiuc) that would be
> > > > great :)
> > > >
> > > > Could something like "select EFI if SYSFB" work?
> > >
> > > You probably mean the reverse here:
> > >
> > >       select SYSFB if EFI && !HYPERV_VTL_MODE
> >
> > Yes, this is one approach I was thinking about. However, this problem
> > exposed the somewhat broader topic that at least for ARM64 normal
> > VMs, CONFIG_HYPERV really does have a dependency on EFI, and that
> > dependency isn't expressed anywhere. For x86/x64, I want to run some
> > experiments to be sure a Generation 1 VM really will build and boot
> > with CONFIG_EFI=n. Then if we can do so, I'd rather add the correct
> > broader dependency on EFI than embedding the dependency just in
> > the SYSFB selection.
> 
> I've built and tested x86/x64 Generation 1 VMs with CONFIG_EFI=n,
> and I don't see any problems. No build-time EFI dependencies have
> accidently crept into the Gen1 code paths over the years. Since
> Roman has confirmed that VTL2 images do not use EFI, we could
> express CONFIG_HYPERV's broader dependency on EFI as:
> 
>      depends on EFI if ARM64 && !HYPERV_VTL_MODE
> 
> which would allow building an image without EFI for an x86/x64
> Generation 1 VM. The newly added "select SYSFB" entry would do the
> right thing and stay unchanged.
> 
> An alternate viewpoint is that we've always built Hyper-V x86/x64
> guest images to be portable between Generation 1 or Generation 2
> VMs, and that allowing x86/x64 images with CONFIG_EFI=n for Gen 1
> VMs only isn't necessary. In that case we could just add
> 
>    depends on EFI if !HYPERV_VTL_MODE
> 
> I lean slightly toward the first of the two, and not requiring EFI on
> x86/x64 if someone really wanted to build an image that only runs
> on Gen 1 VMs. But the downside is that someone who built such an
> image might be surprised it won't run on a Gen 2 VM. Anyone at
> Microsoft want to weigh in on the choice?
> 
> Michael

What I suggested doesn't work. The "depends on" statement
doesn't take an "if" clause. :-(

There are other ways to express the HYPERV dependency on EFI that is
conditional. But if the condition includes HYPERV_VTL_MODE (which
it needs to), then there's a dependency loop because
HYPERV_VTL_MODE depends on HYPERV. So that doesn't work
either.

To solve the immediate problem, we'll just have to do

    select SYSFB if EFI && !HYPERV_VTL_MODE

Separately, if we want to express the broader dependency of
HYPERV on EFI (at least for ARM64), then the dependency of
HYPERV_VTL_MODE on HYPERV will need to go away. Three
months back I had suggested not creating that dependency [1],
but the eventual decision was to add it. [2, and follow discussion]
We would need to revisit that discussion.

Arnd -- if you'd prefer that I submit the patch, let me know.
I created the original problem and can clean up the mess. :-)

Michael

[1] https://lore.kernel.org/lkml/SN6PR02MB4157B22BD56677EFBD215D87D4BE2@SN6PR02MB4157.namprd02.prod.outlook.com/
[2] https://lore.kernel.org/linux-hyperv/20250307220304.247725-4-romank@linux.microsoft.com/

Re: [PATCH] hv: add CONFIG_EFI dependency

[Arnd Bergmann]

On Fri, Jun 13, 2025, at 17:50, Michael Kelley wrote:
> From: Michael Kelley <mhklinux@outlook.com> Sent: Tuesday, June 10, 
>
> There are other ways to express the HYPERV dependency on EFI that is
> conditional. But if the condition includes HYPERV_VTL_MODE (which
> it needs to), then there's a dependency loop because
> HYPERV_VTL_MODE depends on HYPERV. So that doesn't work
> either.
>
> To solve the immediate problem, we'll just have to do
>
>     select SYSFB if EFI && !HYPERV_VTL_MODE

Right. Technically, you could do

    select HYPERV_VTL_MODE if !EFI

but that makes no sense from a usability point of view.

> Separately, if we want to express the broader dependency of
> HYPERV on EFI (at least for ARM64), then the dependency of
> HYPERV_VTL_MODE on HYPERV will need to go away. Three
> months back I had suggested not creating that dependency [1],
> but the eventual decision was to add it. [2, and follow discussion]
> We would need to revisit that discussion.
>
> Arnd -- if you'd prefer that I submit the patch, let me know.
> I created the original problem and can clean up the mess. :-)

Yes, please do, I trust you will come up with a better patch
description than I would.

      Arnd