From: Michael Kelley <mhkli...@outlook.com> Sent: Tuesday, June 10, 2025 11:46
AM
>
> From: Michael Kelley <mhkli...@outlook.com> Sent: Tuesday, June 10, 2025 9:17
> AM
> >
> > 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'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/sn6pr02mb4157b22bd56677efbd215d87d4...@sn6pr02mb4157.namprd02.prod.outlook.com/
[2]
https://lore.kernel.org/linux-hyperv/20250307220304.247725-4-rom...@linux.microsoft.com/
