On Mon, May 04, 2026 at 05:48:46PM -0700, Dexuan Cui wrote: > 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 > 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 > host has assigned to the framebuffer. > > This is especially an issue if pci-hyperv is built-in and hyperv-drm is > built as a module. Consequently, the kdump/kexec 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. The issue described here has existed > for SR-IOV VF NICs since day one of the pci-hyperv driver, and has been > worked around on x64 when possible. With the recent introduction of > ARM64 VMs that boot from NVMe, there is no workaround, so we need a > formal fix. > > On Gen2 VMs, if the screen.lfb_base is 0 in the kdump/kexec kernel [1], > fall back to the low MMIO base, which should be equal to the framebuffer > MMIO base [2] (the statement is true according to my testing on x64 > Windows Server 2016, and on x64 and ARM64 Windows Server 2025 and on > 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, > but cap the reservation to 128MB, which is the required framebuffer size > of the highest resolution 7680*4320 supported by Hyper-V. > > 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 for the low MMIO range). > > 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, > 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. > > Note: normally Gen1 VMs don't have the MMIO conflict issue because the > framebuffer MMIO range (which is hardcoded to base=4GB-128MB and > size=64MB for Gen1 VMs by the host) is always reported via the legacy PCI > graphics device's BAR, so the kdump/kexec kernel can reserve the 64MB > MMIO range; however, if the VM is configured to use a very high resolution > 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] > 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/ > > Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft > Hyper-V VMs") > CC: [email protected] > Signed-off-by: Dexuan Cui <[email protected]> > --- Thanks for the updated patch. I re-tested this on a D2pdsv6 and was able to confirm that without the patch the NIC drivers in the dump environment didn't attach because of a PCI conflict. With the patch the drivers attached and it was possible to successfully collect a kdump.
Tested-by: Krister Johansen <[email protected]> -K
