Message-ID:
 <SN6PR02MB4157D600219C00D33D00C3B4D477A@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Fri, 13 Jun 2025 15:50:49 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Michael Kelley <mhklinux@...look.com>, Arnd Bergmann <arnd@...db.de>,
	Roman Kisel <romank@...ux.microsoft.com>, Arnd Bergmann <arnd@...nel.org>
CC: Dexuan Cui <decui@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>,
	"K. Y. Srinivasan" <kys@...rosoft.com>, "linux-hyperv@...r.kernel.org"
	<linux-hyperv@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "nunodasneves@...ux.microsoft.com"
	<nunodasneves@...ux.microsoft.com>, Saurabh Singh Sengar
	<ssengar@...ux.microsoft.com>, Wei Liu <wei.liu@...nel.org>
Subject: RE: [PATCH] hv: add CONFIG_EFI dependency

From: Michael Kelley <mhklinux@...look.com> Sent: Tuesday, June 10, 2025 11:46 AM
> 
> From: Michael Kelley <mhklinux@...look.com> Sent: Tuesday, June 10, 2025 9:17 AM
> >
> > From: Arnd Bergmann <arnd@...db.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/

Powered by blists - more mailing lists