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

> 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

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