From: Dexuan Cui <[email protected]> Sent: Tuesday, April 28, 2026 6:58 PM > > From: Michael Kelley <[email protected]> Sent: Thursday, April 23, 2026 > > 10:40 AM
[snip] > > > Question about Gen 1 VMs: If the Linux frame buffer driver moves > > the frame buffer somewhere other than the default location, and > > then the VM does a kexec/kdump, what does the legacy PCI graphic > > device BAR report as the frame buffer location? Does it *always* > > report 4G-128MB, or does it report the new location? I can run > > It always reports 4G-128MB. OK, good to know. I was hoping it might report the new location. :-( > BTW, I suspect a Gen2 VM may have the same issue, i.e. > currently we only reserve 8MB below 4GB; if hyperv_drm uses > high MMIO, I suspect the UEFI firmware would still report the > same original low MMIO framebuffer base/size to the kdump kernel, > but there is no easy way to verify this for Gen2 VMs... > [snip] > > However, when the kdump kernel starts to run, and I print the > pci_resource_start(pdev, 0) and pci_resource_len(pdev, 0) > from vmbus_reserve_fb(), I still see 4G-128MB: > [ 12.506159] Gen1 VM: start=0xf8000000, size=0x4000000 > > In this case, we can't really fix the MMIO conflict, e.g. > if both hv_pci and hyperv_drm are built as modules, then > the order of loading them can be nondeterministic:if the order > in the first kernel is different from the order in > the kdump kernel, we run into trouble. Yep. > > If the order is deterministic (e.g. hv_pci is > built-in, and hyperv_drm is built as a module), > we should be good since both allocates MMIO from > the high MMIO range in a deterministic way. > Yep. Thanks, Michael
