Hi Dexuan, Thanks for making the amendments, and thank you Michael for all your reviews.
Since you posted the diff to the V3, I went and tested the V3 patch. I have tested this patch on Azure with: - Standard_D4ads_v5 - Standard_D4ads_v6 with the following images: "Ubuntu Server 22.04 LTS - x64 Gen2" "Ubuntu Server 24.04 LTS - x64 Gen2" with the following kernels: - 7.1-rc2 at 5862221fddede6bb15566ab3c1f23a3c353da5e1 - 7.1-rc2 at 5862221fddede6bb15566ab3c1f23a3c353da5e1 + the V3 patch Without this patch, I could reproduce the issue on 22.04 + v6 based instance types. I can confirm that with this patch, v6 instance types can correctly kdump and create a vmcore correctly and restart correctly without running into MMIO issues. I can confirm that with this patch, v5 instance types continue to operate the same as they did previously. Tested-by: Matthew Ruffell <[email protected]> Thanks, Matthew On Thu, 7 May 2026 at 13:11, Dexuan Cui <[email protected]> wrote: > > > From: Michael Kelley <[email protected]> > > 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 <[email protected]> > 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/sa1pr21mb692176c1bc53bfc9eae5cf8ebf...@sa1pr21mb6921.namprd21.prod.outlook.com/ > [2] > https://lore.kernel.org/all/sa1pr21mb69218f955b62dff62e3e88d2bf...@sa1pr21mb6921.namprd21.prod.outlook.com/ > -[3] > https://lore.kernel.org/all/sa1pr21mb69213486f821ca5a2c793c81bf...@sa1pr21mb6921.namprd21.prod.outlook.com/ > -[4] > https://lore.kernel.org/all/sn6pr02mb415726b17d5a6027cd1717e8d4...@sn6pr02mb4157.namprd02.prod.outlook.com/ > +[3] > https://lore.kernel.org/all/sn6pr02mb415726b17d5a6027cd1717e8d4...@sn6pr02mb4157.namprd02.prod.outlook.com/ > +[4] > https://lore.kernel.org/all/sa1pr21mb69213486f821ca5a2c793c81bf...@sa1pr21mb6921.namprd21.prod.outlook.com/ > > Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft > Hyper-V VMs") > CC: [email protected] > +Reviewed-by: Michael Kelley <[email protected]> > +Tested-by: Krister Johansen <[email protected]> > Signed-off-by: Dexuan Cui <[email protected]> > --- > > @@ -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 <[email protected]> > > Thanks a lot!
