Message-ID:
 <SN6PR02MB4157D3A61C5DB1357267D712D46AA@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Tue, 10 Jun 2025 18:45:36 +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 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

> 
> >
> > 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/

Powered by blists - more mailing lists