From: Arnd Bergmann <a...@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-...@intel.com/
