RE: [PATCH v2] Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs

[Dexuan Cui]

> From: Michael Kelley <mhklinux@xxxxxxxxxxx>
> Sent: Wednesday, May 6, 2026 8:14 AM
> > ...
> > +				/*
> > +				 * If the kdump kernel's lfb_base is 0,
> 
> Nit:  The case of lfb_base is 0 applies to kexec and kdump kernels, and also to
> CVMs.

Thanks for catching this! I'm going to post this v3 later today.

--- v2-0001-Drivers-hv-vmbus-Improve-the-logic-of-reserving-fb_m.patch  2026-05-04 17:48:23.486911073 -0700
+++ v3-0001-Drivers-hv-vmbus-Improve-the-logic-of-reserving-fb_m.patch  2026-05-06 18:03:42.922469286 -0700
@@ -1,15 +1,15 @@
 From 5d817788d65febdc0451e8a88277778794fe87b2 Mon Sep 17 00:00:00 2001
 From: Dexuan Cui <decui@xxxxxxxxxxxxx>
 Date: Thu, 16 Apr 2026 04:30:21 +0000
-Subject: [PATCH v2] Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on
+Subject: [PATCH v3] Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on
  Gen2 VMs

 If vmbus_reserve_fb() in the kdump/kexec kernel fails to properly reserve
 the framebuffer MMIO range (which is below 4GB) due to a Gen2 VM's
 screen.lfb_base being zero [1], there is an MMIO conflict between the
 drivers hyperv-drm and pci-hyperv: when the driver pci-hyperv's
-hv_pci_allocate_bridge_windows() calls vmbus_allocate_mmio() to get a
-32-bit MMIO range, it may get an MMIO range that overlaps with the
+hv_allocate_config_window() calls vmbus_allocate_mmio() to get an
+MMIO range, typically it gets a 32-bit MMIO range that overlaps with the
 framebuffer MMIO range, and later hv_pci_enter_d0() fails with an
 error message "PCI Pass-through VSP failed D0 Entry with status" since
 the host thinks that PCI devices must not use MMIO space that the
@@ -31,7 +31,7 @@
 Azure. I checked with the Hyper-V team and they said the statement should
 continue to be true for Gen2 VMs). In the first kernel, screen.lfb_base
 is not 0; if the user specifies a very high resolution, it's not enough
-to only reserve 8MB: in this case, reserve half of the space below 4GB,
+to only reserve 8MB: let's always reserve half of the space below 4GB,
 but cap the reservation to 128MB, which is the required framebuffer size
 of the highest resolution 7680*4320 supported by Hyper-V.

@@ -42,7 +42,7 @@
 Note: vmbus_reserve_fb() now also reserves an MMIO range at the beginning
 of the low MMIO range on CVMs, which have no framebuffers (the
 'screen.lfb_base' in vmbus_reserve_fb() is 0 for CVMs), just in case the
-host might treat the beginning of the low MMIO range specially [4]. BTW,
+host might treat the beginning of the low MMIO range specially [3]. BTW,
 the OpenHCL kernel is not affected by the change, because that kernel
 boots with DeviceTree rather than ACPI (so vmbus_reserve_fb() won't run
 there), and there is no framebuffer device for that kernel.
@@ -55,18 +55,20 @@
 and the required framebuffer size exceeds 64MB (AFAIK, in practice, this
 isn't a typical configuration by users), the hyperv-drm driver may need to
 allocate an MMIO range above 4GB and change the framebuffer MMIO location
-to the allocated MMIO range -- in this case, there can still be issues [3]
+to the allocated MMIO range -- in this case, there can still be issues [4]
 which can't be easily fixed: any possible affected Gen1 users would have
 to use a resolution whose framebuffer size is <= 64MB, or switch to Gen2
 VMs.

 [1] https://lore.kernel.org/all/SA1PR21MB692176C1BC53BFC9EAE5CF8EBF51A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
 [2] https://lore.kernel.org/all/SA1PR21MB69218F955B62DFF62E3E88D2BF222@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
-[3] https://lore.kernel.org/all/SA1PR21MB69213486F821CA5A2C793C81BF342@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
-[4] https://lore.kernel.org/all/SN6PR02MB415726B17D5A6027CD1717E8D4342@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
+[3] https://lore.kernel.org/all/SN6PR02MB415726B17D5A6027CD1717E8D4342@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
+[4] https://lore.kernel.org/all/SA1PR21MB69213486F821CA5A2C793C81BF342@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/

 Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
 CC: stable@xxxxxxxxxxxxxxx
+Reviewed-by: Michael Kelley <mhklinux@xxxxxxxxxxx>
+Tested-by: Krister Johansen <kjlx@xxxxxxxxxxxxxxxxxx>
 Signed-off-by: Dexuan Cui <decui@xxxxxxxxxxxxx>
 ---

@@ -104,6 +106,18 @@
 Hi Hardik, I'm not adding your Reviewed-by since the patch changed.
 Please review the v2.

+
+Changes since v2:
+    Fixed the commit message:
+        hv_pci_allocate_bridge_windows() -> hv_allocate_config_window()
+
+    Changed the "kdump" in the comment to "kdump/kexec or CVM" [Michael Kelley]
+
+    Fixed the order of the "[3]" and "[4]" in the commit message.
+
+    Added Krister's Tested-by.
+    Added Michael's Reviewed-by.
+
  drivers/hv/vmbus_drv.c | 29 ++++++++++++++++++++++++++---
  1 file changed, 26 insertions(+), 3 deletions(-)

@@ -141,8 +155,8 @@
 +                              pr_warn("Unexpected low mmio base %pa\n", &low_mmio_base);
 +                      } else {
 +                              /*
-+                               * If the kdump kernel's lfb_base is 0,
-+                               * fall back to the low mmio base.
++                               * If the kdump/kexec or CVM kernel's lfb_base
++                               * is 0, fall back to the low mmio base.
 +                               */
 +                              if (!start)
 +                                      start = low_mmio_base;


> Modulo my nit about the comment,
> 
> Reviewed-by: Michael Kelley <mhklinux@xxxxxxxxxxx>

Thanks a lot!