RE: [PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window

[Michael Kelley]

From: Dexuan Cui <DECUI@xxxxxxxxxxxxx> Sent: Thursday, April 2, 2026 12:24 PM
> 
> > From: Michael Kelley <mhklinux@xxxxxxxxxxx>
> > Sent: Friday, January 23, 2026 10:28 AM
> >  ...
> > One more thought here: Is commit 96959283a58d relevant? The
> > commit message describes a scenario where vmbus_reserve_fb()
> > doesn't do anything because CONFIG_SYSFB is not set. Looking at
> > the code for vmbus_reserve_fb(), it doing nothing might imply that
> > screen_info.lfb_base is 0. But when CONFIG_SYSFB is not set,
> > screen_info.lfb_base is just ignored, with the same result. This behavior
> > started with the 6.7 kernel due to commit a07b50d80ab6.
> >
> > Note that commit 96959283a58d has a follow-on to correct a
> > problem when CONFIG_EFI is not set.  See commit 7b89a44b2e8c.
> > If there's a reason to backport 96959283a58d, also get
> > 7b89a44b2e8c.
> >
> > Michael
> 
> In my opinion,
> 96959283a58d ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests")
> is not a good fix for a07b50d80ab6: the commit message of a07b50d80ab6
> says "the vmbus_drv code marks the original EFI framebuffer as reserved, but
> this is not required if there is no sysfb" -- IMO the message is incorrect.
> 
> Even if CONFIG_SYSFB is not set, we still need to reserve the framebuffer
> MMIO range, because we need to make sure that hv_pci doesn't allocate
> MMIO from there.
> 
> 96959283a58d adds "select SYSFB if !HYPERV_VTL_MODE", but we can
> still manually unset CONFIG_SYSFB (I happened to do this when debugging
> the kdump issue), and hv_pci won't work.

Just curious -- how would you manually unset CONFIG_SYSFB? The kernel
makefile always resync's .config against the Kconfig rules, which would add
CONFIG_SYSFB back again. The Kconfig files essentially say that removing
CONFIG_SYSFB is an invalid configuration.

> 
> IMO vmbus_reserve_fb() should unconditionally reserve the frame buffer
> MMIO range. I'll post a patch like this:
> 
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -2395,10 +2398,8 @@ static void __maybe_unused vmbus_reserve_fb(void)
> 
>         if (efi_enabled(EFI_BOOT)) {
>                 /* Gen2 VM: get FB base from EFI framebuffer */
> -               if (IS_ENABLED(CONFIG_SYSFB)) {
> -                       start = sysfb_primary_display.screen.lfb_base;
> -                       size = max_t(__u32, sysfb_primary_display.screen.lfb_size, 0x800000);
> -               }
> +               start = sysfb_primary_display.screen.lfb_base;
> +               size = max_t(__u32, sysfb_primary_display.screen.lfb_size, 0x800000);

On arm64 the existence of sysfb_primary_display is conditional on
several config variables, including CONFIG_SYSFB and CONFIG_EFI_EARLYCON.
(see drivers/firmware/efi/efi-init.c) If you can take away CONFIG_SYSFB, you
could also take away CONFIG_EFI_EARLYCON and end up with build error on
arm64. So I'm not clear how this approach would be more robust against
invalid .config changes.

Also this recent patch set [1] submitted by Thomas Zimmerman is even more
explicit about sysfb_primary_display being conditional on CONFIG_SYSFB.

Michael

[1] https://lore.kernel.org/linux-hyperv/20260402092305.208728-1-tzimmermann@xxxxxxx/

>         } else {
>                 /* Gen1 VM: get FB base from PCI */
>                 pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
> 
> 
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 7937ac0cbd0f..78d7f8c66278 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -9,7 +9,6 @@ config HYPERV
>         select PARAVIRT
>         select X86_HV_CALLBACK_VECTOR if X86
>         select OF_EARLY_FLATTREE if OF
> -       select SYSFB if EFI && !HYPERV_VTL_MODE
>         select IRQ_MSI_LIB if X86
>         help
>           Select this option to run Linux as a Hyper-V client operating
> 
> Thanks,
> Dexuan