Thanks Dexuan for all your hard work and analysis on this 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 merge window at c1f49dea2b8f335813d3b348fd39117fb8efb428 - 7.1 merge window at c1f49dea2b8f335813d3b348fd39117fb8efb428 + this 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]> On Sat, 18 Apr 2026 at 08:24, Krister Johansen <[email protected]> wrote: > > On Thu, Apr 16, 2026 at 11:35:29AM -0700, Dexuan Cui wrote: > > If vmbus_reserve_fb() in the kdump kernel fails to properly reserve the > > framebuffer MMIO range 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. > > This is especially an issue if pci-hyperv is built-in and hyperv_drm is > > built as a module. Consequently, the kdump kernel fails to detect PCI > > devices via pci-hyperv, and may fail to mount the root file system, > > which may reside in a NVMe disk. > > > > On Gen2 VMs, if the screen.lfb_base is 0 in the kdump kernel, fall > > back to the low MMIO base, which should be equal to the framebuffer > > MMIO base (Tested on x64 Windows Server 2016, and on x64 and ARM64 Windows > > Server 2025 and on Azure) [2]. In the first kernel, screen.lfb_base > > is not 0; if the user specifies a high resolution, it's not enough to > > only reserve 8MB: in this case, 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. > > > > Add the cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) check, because a CoCo > > VM (i.e. Confidential VM) on Hyper-V doesn't have any framebuffer > > device, so there is no need to reserve any MMIO for it. > > > > While at it, fix the comparison "end > VTPM_BASE_ADDRESS" by changing > > the > to >=. Here the 'end' is an inclusive end (typically, it's > > 0xFFFF_FFFF). > > > > [1] > > https://lore.kernel.org/all/sa1pr21mb692176c1bc53bfc9eae5cf8ebf...@sa1pr21mb6921.namprd21.prod.outlook.com/ > > [2] > > https://lore.kernel.org/all/sa1pr21mb69218f955b62dff62e3e88d2bf...@sa1pr21mb6921.namprd21.prod.outlook.com/ > > > > Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft > > Hyper-V VMs") > > CC: [email protected] > > Signed-off-by: Dexuan Cui <[email protected]> > > --- > > drivers/hv/vmbus_drv.c | 30 ++++++++++++++++++++++++++++-- > > 1 file changed, 28 insertions(+), 2 deletions(-) > > Thanks for the updated patch. I tested this on the arm64 instances that > had been failing and was able to confirm that without it present the > failure still occurred, but with the new patch networking was able to > attach correctly in the dump environment and kdumps were successful. > > Tested-by: Krister Johansen <[email protected]> > > -K
