[PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window

[PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window

[Dexuan Cui]

There has been a longstanding MMIO conflict between the pci_hyperv
driver's config_window (see hv_allocate_config_window()) and the
hyperv_drm (or hyperv_fb) driver (see hyperv_setup_vram()): typically
both get MMIO from the low MMIO range below 4GB; this is not an issue
in the normal kernel since the VMBus driver reserves the framebuffer
MMIO in vmbus_reserve_fb(), so the drm driver's hyperv_setup_vram() can
always get the reserved framebuffer MMIO; however, a Gen2 VM's kdump
kernel fails to reserve the framebuffer MMIO in vmbus_reserve_fb() because
the screen_info.lfb_base is zero in the kdump kernel: the screen_info
is not initialized at all in the kdump kernel, because the EFI stub
code, which initializes screen_info, doesn't run in the case of kdump.

When vmbus_reserve_fb() fails to reserve the framebuffer MMIO in the
kdump kernel, if pci_hyperv in the kdump kernel loads before hyperv_drm
loads, pci_hyperv's vmbus_allocate_mmio() gets the framebuffer MMIO
and tries to use it, but since the host thinks that the MMIO range is
still in use by hyperv_drm, the host refuses to accept the MMIO range
as the config window, and pci_hyperv's hv_pci_enter_d0() errors out:
"PCI Pass-through VSP failed D0 Entry with status c0370048".

This PCI error in the kdump kernel was not fatal in the past because
the kdump kernel normally doesn't reply on pci_hyperv, and the root
file system is on a VMBus SCSI device.

Now, a VM on Azure can boot from NVMe, i.e. the root FS can be on a
NVMe device, which depends on pci_hyperv. When the PCI error occurs,
the kdump kernel fails to boot up since no root FS is detected.

Fix the MMIO conflict by allocating MMIO above 4GB for the
config_window.

Note: we still need to figure out how to address the possible MMIO
conflict between hyperv_drm and pci_hyperv in the case of 32-bit PCI
MMIO BARs, but that's of low priority because all PCI devices available
to a Linux VM on Azure should use 64-bit BARs and should not use 32-bit
BARs -- I checked Mellanox VFs, MANA VFs, NVMe devices, and GPUs in
Linux VMs on Azure, and found no 32-bit BARs.

Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: stable@vger.kernel.org
---
 drivers/pci/controller/pci-hyperv.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index 1e237d3538f9..a6aecb1b5cab 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -3406,9 +3406,13 @@ static int hv_allocate_config_window(struct hv_pcibus_device *hbus)
 
 	/*
 	 * Set up a region of MMIO space to use for accessing configuration
-	 * space.
+	 * space. Use the high MMIO range to not conflict with the hyperv_drm
+	 * driver (which normally gets MMIO from the low MMIO range) in the
+	 * kdump kernel of a Gen2 VM, which fails to reserve the framebuffer
+	 * MMIO range in vmbus_reserve_fb() due to screen_info.lfb_base being
+	 * zero in the kdump kernel.
 	 */
-	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, 0, -1,
+	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, SZ_4G, -1,
 				  PCI_CONFIG_MMIO_LENGTH, 0x1000, false);
 	if (ret)
 		return ret;
-- 
2.43.0

RE: [PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window

[Michael Kelley]

From: Dexuan Cui <decui@microsoft.com> Sent: Wednesday, January 21, 2026 6:04 PM
> 
> There has been a longstanding MMIO conflict between the pci_hyperv
> driver's config_window (see hv_allocate_config_window()) and the
> hyperv_drm (or hyperv_fb) driver (see hyperv_setup_vram()): typically
> both get MMIO from the low MMIO range below 4GB; this is not an issue
> in the normal kernel since the VMBus driver reserves the framebuffer
> MMIO in vmbus_reserve_fb(), so the drm driver's hyperv_setup_vram() can
> always get the reserved framebuffer MMIO; however, a Gen2 VM's kdump
> kernel fails to reserve the framebuffer MMIO in vmbus_reserve_fb() because
> the screen_info.lfb_base is zero in the kdump kernel: the screen_info
> is not initialized at all in the kdump kernel, because the EFI stub
> code, which initializes screen_info, doesn't run in the case of kdump.

I don't think this is correct. Yes, the EFI stub doesn't run, but screen_info
should be initialized in the kdump kernel by the code that loads the
kdump kernel into the reserved crash memory. See discussion in the commit
message for commit 304386373007.

I wonder if commit a41e0ab394e4 broke the initialization of screen_info
in the kdump kernel. Or perhaps there is now a rev-lock between the kernel
with this commit and a new version of the user space kexec command.

There's a parameter to the kexec() command that governs whether it
uses the kexec_file_load() system call or the kexec_load() system call.
I wonder if that parameter makes a difference in the problem described
for this patch.

I can't immediately remember if, when I was working on commit
304386373007, I tested kdump in a Gen 2 VM with an NVMe OS disk to
ensure that MMIO space was properly allocated to the frame buffer
driver (either hyperv_fb or hyperv_drm). I'm thinking I did, but tomorrow
I'll check for any definitive notes on that.

Michael

> 
> When vmbus_reserve_fb() fails to reserve the framebuffer MMIO in the
> kdump kernel, if pci_hyperv in the kdump kernel loads before hyperv_drm
> loads, pci_hyperv's vmbus_allocate_mmio() gets the framebuffer MMIO
> and tries to use it, but since the host thinks that the MMIO range is
> still in use by hyperv_drm, the host refuses to accept the MMIO range
> as the config window, and pci_hyperv's hv_pci_enter_d0() errors out:
> "PCI Pass-through VSP failed D0 Entry with status c0370048".
> 
> This PCI error in the kdump kernel was not fatal in the past because
> the kdump kernel normally doesn't reply on pci_hyperv, and the root
> file system is on a VMBus SCSI device.
> 
> Now, a VM on Azure can boot from NVMe, i.e. the root FS can be on a
> NVMe device, which depends on pci_hyperv. When the PCI error occurs,
> the kdump kernel fails to boot up since no root FS is detected.
> 
> Fix the MMIO conflict by allocating MMIO above 4GB for the
> config_window.
> 
> Note: we still need to figure out how to address the possible MMIO
> conflict between hyperv_drm and pci_hyperv in the case of 32-bit PCI
> MMIO BARs, but that's of low priority because all PCI devices available
> to a Linux VM on Azure should use 64-bit BARs and should not use 32-bit
> BARs -- I checked Mellanox VFs, MANA VFs, NVMe devices, and GPUs in
> Linux VMs on Azure, and found no 32-bit BARs.
> 
> Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> Cc: stable@vger.kernel.org
> ---
>  drivers/pci/controller/pci-hyperv.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index 1e237d3538f9..a6aecb1b5cab 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -3406,9 +3406,13 @@ static int hv_allocate_config_window(struct
> hv_pcibus_device *hbus)
> 
>  	/*
>  	 * Set up a region of MMIO space to use for accessing configuration
> -	 * space.
> +	 * space. Use the high MMIO range to not conflict with the hyperv_drm
> +	 * driver (which normally gets MMIO from the low MMIO range) in the
> +	 * kdump kernel of a Gen2 VM, which fails to reserve the framebuffer
> +	 * MMIO range in vmbus_reserve_fb() due to screen_info.lfb_base being
> +	 * zero in the kdump kernel.
>  	 */
> -	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, 0, -1,
> +	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, SZ_4G, -1,
>  				  PCI_CONFIG_MMIO_LENGTH, 0x1000, false);
>  	if (ret)
>  		return ret;
> --
> 2.43.0

RE: [PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window

[Long Li]

> From: Dexuan Cui <decui@microsoft.com> Sent: Wednesday, January 21, 2026
> 6:04 PM
> >
> > There has been a longstanding MMIO conflict between the pci_hyperv
> > driver's config_window (see hv_allocate_config_window()) and the
> > hyperv_drm (or hyperv_fb) driver (see hyperv_setup_vram()): typically
> > both get MMIO from the low MMIO range below 4GB; this is not an issue
> > in the normal kernel since the VMBus driver reserves the framebuffer
> > MMIO in vmbus_reserve_fb(), so the drm driver's hyperv_setup_vram()
> > can always get the reserved framebuffer MMIO; however, a Gen2 VM's
> > kdump kernel fails to reserve the framebuffer MMIO in
> > vmbus_reserve_fb() because the screen_info.lfb_base is zero in the
> > kdump kernel: the screen_info is not initialized at all in the kdump
> > kernel, because the EFI stub code, which initializes screen_info, doesn't run in
> the case of kdump.
> 
> I don't think this is correct. Yes, the EFI stub doesn't run, but screen_info should
> be initialized in the kdump kernel by the code that loads the kdump kernel into
> the reserved crash memory. See discussion in the commit message for commit
> 304386373007.

On AMD64 the screen_info is passed through kexec system call. But this is not the case for ARM64, it relies on EFI to get screen_info.

However, Hyper-v guarantees the framebuffer MMIO is below 4GB. So, the patch works by allocating PCI MMIO separately from that of the framebuffer.

Long

> 
> I wonder if commit a41e0ab394e4 broke the initialization of screen_info in the
> kdump kernel. Or perhaps there is now a rev-lock between the kernel with this
> commit and a new version of the user space kexec command.
> 
> There's a parameter to the kexec() command that governs whether it uses the
> kexec_file_load() system call or the kexec_load() system call.
> I wonder if that parameter makes a difference in the problem described for this
> patch.
> 
> I can't immediately remember if, when I was working on commit 304386373007, I
> tested kdump in a Gen 2 VM with an NVMe OS disk to ensure that MMIO space
> was properly allocated to the frame buffer driver (either hyperv_fb or
> hyperv_drm). I'm thinking I did, but tomorrow I'll check for any definitive notes on
> that.
> 
> Michael
> 
> >
> > When vmbus_reserve_fb() fails to reserve the framebuffer MMIO in the
> > kdump kernel, if pci_hyperv in the kdump kernel loads before
> > hyperv_drm loads, pci_hyperv's vmbus_allocate_mmio() gets the
> > framebuffer MMIO and tries to use it, but since the host thinks that
> > the MMIO range is still in use by hyperv_drm, the host refuses to
> > accept the MMIO range as the config window, and pci_hyperv's
> hv_pci_enter_d0() errors out:
> > "PCI Pass-through VSP failed D0 Entry with status c0370048".
> >
> > This PCI error in the kdump kernel was not fatal in the past because
> > the kdump kernel normally doesn't reply on pci_hyperv, and the root
> > file system is on a VMBus SCSI device.
> >
> > Now, a VM on Azure can boot from NVMe, i.e. the root FS can be on a
> > NVMe device, which depends on pci_hyperv. When the PCI error occurs,
> > the kdump kernel fails to boot up since no root FS is detected.
> >
> > Fix the MMIO conflict by allocating MMIO above 4GB for the
> > config_window.
> >
> > Note: we still need to figure out how to address the possible MMIO
> > conflict between hyperv_drm and pci_hyperv in the case of 32-bit PCI
> > MMIO BARs, but that's of low priority because all PCI devices
> > available to a Linux VM on Azure should use 64-bit BARs and should not
> > use 32-bit BARs -- I checked Mellanox VFs, MANA VFs, NVMe devices, and
> > GPUs in Linux VMs on Azure, and found no 32-bit BARs.
> >
> > Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for
> > Microsoft Hyper-V VMs")
> > Signed-off-by: Dexuan Cui <decui@microsoft.com>
> > Cc: stable@vger.kernel.org
> > ---
> >  drivers/pci/controller/pci-hyperv.c | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pci-hyperv.c
> > b/drivers/pci/controller/pci-hyperv.c
> > index 1e237d3538f9..a6aecb1b5cab 100644
> > --- a/drivers/pci/controller/pci-hyperv.c
> > +++ b/drivers/pci/controller/pci-hyperv.c
> > @@ -3406,9 +3406,13 @@ static int hv_allocate_config_window(struct
> > hv_pcibus_device *hbus)
> >
> >  	/*
> >  	 * Set up a region of MMIO space to use for accessing configuration
> > -	 * space.
> > +	 * space. Use the high MMIO range to not conflict with the hyperv_drm
> > +	 * driver (which normally gets MMIO from the low MMIO range) in the
> > +	 * kdump kernel of a Gen2 VM, which fails to reserve the framebuffer
> > +	 * MMIO range in vmbus_reserve_fb() due to screen_info.lfb_base being
> > +	 * zero in the kdump kernel.
> >  	 */
> > -	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, 0, -1,
> > +	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, SZ_4G, -1,
> >  				  PCI_CONFIG_MMIO_LENGTH, 0x1000, false);
> >  	if (ret)
> >  		return ret;
> > --
> > 2.43.0

RE: [PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window

[Michael Kelley]

From: Long Li <longli@microsoft.com> Sent: Thursday, January 22, 2026 11:14 AM
> 
> > From: Dexuan Cui <decui@microsoft.com> Sent: Wednesday, January 21, 2026 6:04 PM
> > >
> > > There has been a longstanding MMIO conflict between the pci_hyperv
> > > driver's config_window (see hv_allocate_config_window()) and the
> > > hyperv_drm (or hyperv_fb) driver (see hyperv_setup_vram()): typically
> > > both get MMIO from the low MMIO range below 4GB; this is not an issue
> > > in the normal kernel since the VMBus driver reserves the framebuffer
> > > MMIO in vmbus_reserve_fb(), so the drm driver's hyperv_setup_vram()
> > > can always get the reserved framebuffer MMIO; however, a Gen2 VM's
> > > kdump kernel fails to reserve the framebuffer MMIO in
> > > vmbus_reserve_fb() because the screen_info.lfb_base is zero in the
> > > kdump kernel: the screen_info is not initialized at all in the kdump
> > > kernel, because the EFI stub code, which initializes screen_info, doesn't run in
> > the case of kdump.
> >
> > I don't think this is correct. Yes, the EFI stub doesn't run, but screen_info should
> > be initialized in the kdump kernel by the code that loads the kdump kernel into
> > the reserved crash memory. See discussion in the commit message for commit
> > 304386373007.
> 
> On AMD64 the screen_info is passed through kexec system call. But this is not the case
> for ARM64, it relies on EFI to get screen_info.

Hmmm. So does the problem described here only happen on arm64? If so, that
might be worth noting in the commit message.

I found my notes from working on commit 304386373007. I don't remember
testing on arm64, and my notes don't mention it. So I'm wondering if the problem
fixed by that commit could happen on arm64. That's potentially a separate issue
from this one. I'll do some experiments to verify.

> 
> However, Hyper-v guarantees the framebuffer MMIO is below 4GB. So, the patch works
> by allocating PCI MMIO separately from that of the framebuffer.

Yes, that seems right. But there's still something nagging at me about this,
though I can't immediately identify a problem.  I'll follow up if something
comes to me. :-)

Michael

> 
> Long
> 
> >
> > I wonder if commit a41e0ab394e4 broke the initialization of screen_info in the
> > kdump kernel. Or perhaps there is now a rev-lock between the kernel with this
> > commit and a new version of the user space kexec command.
> >
> > There's a parameter to the kexec() command that governs whether it uses the
> > kexec_file_load() system call or the kexec_load() system call.
> > I wonder if that parameter makes a difference in the problem described for this
> > patch.
> >
> > I can't immediately remember if, when I was working on commit 304386373007, I
> > tested kdump in a Gen 2 VM with an NVMe OS disk to ensure that MMIO space
> > was properly allocated to the frame buffer driver (either hyperv_fb or
> > hyperv_drm). I'm thinking I did, but tomorrow I'll check for any definitive notes on
> > that.
> >
> > Michael
> >
> > >
> > > When vmbus_reserve_fb() fails to reserve the framebuffer MMIO in the
> > > kdump kernel, if pci_hyperv in the kdump kernel loads before
> > > hyperv_drm loads, pci_hyperv's vmbus_allocate_mmio() gets the
> > > framebuffer MMIO and tries to use it, but since the host thinks that
> > > the MMIO range is still in use by hyperv_drm, the host refuses to
> > > accept the MMIO range as the config window, and pci_hyperv's
> > hv_pci_enter_d0() errors out:
> > > "PCI Pass-through VSP failed D0 Entry with status c0370048".
> > >
> > > This PCI error in the kdump kernel was not fatal in the past because
> > > the kdump kernel normally doesn't reply on pci_hyperv, and the root
> > > file system is on a VMBus SCSI device.
> > >
> > > Now, a VM on Azure can boot from NVMe, i.e. the root FS can be on a
> > > NVMe device, which depends on pci_hyperv. When the PCI error occurs,
> > > the kdump kernel fails to boot up since no root FS is detected.
> > >
> > > Fix the MMIO conflict by allocating MMIO above 4GB for the
> > > config_window.
> > >
> > > Note: we still need to figure out how to address the possible MMIO
> > > conflict between hyperv_drm and pci_hyperv in the case of 32-bit PCI
> > > MMIO BARs, but that's of low priority because all PCI devices
> > > available to a Linux VM on Azure should use 64-bit BARs and should not
> > > use 32-bit BARs -- I checked Mellanox VFs, MANA VFs, NVMe devices, and
> > > GPUs in Linux VMs on Azure, and found no 32-bit BARs.
> > >
> > > Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for
> > > Microsoft Hyper-V VMs")
> > > Signed-off-by: Dexuan Cui <decui@microsoft.com>
> > > Cc: stable@vger.kernel.org
> > > ---
> > >  drivers/pci/controller/pci-hyperv.c | 8 ++++++--
> > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/pci-hyperv.c
> > > b/drivers/pci/controller/pci-hyperv.c
> > > index 1e237d3538f9..a6aecb1b5cab 100644
> > > --- a/drivers/pci/controller/pci-hyperv.c
> > > +++ b/drivers/pci/controller/pci-hyperv.c
> > > @@ -3406,9 +3406,13 @@ static int hv_allocate_config_window(struct
> > > hv_pcibus_device *hbus)
> > >
> > >  	/*
> > >  	 * Set up a region of MMIO space to use for accessing configuration
> > > -	 * space.
> > > +	 * space. Use the high MMIO range to not conflict with the hyperv_drm
> > > +	 * driver (which normally gets MMIO from the low MMIO range) in the
> > > +	 * kdump kernel of a Gen2 VM, which fails to reserve the framebuffer
> > > +	 * MMIO range in vmbus_reserve_fb() due to screen_info.lfb_base being
> > > +	 * zero in the kdump kernel.
> > >  	 */
> > > -	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, 0, -1,
> > > +	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, SZ_4G, -1,
> > >  				  PCI_CONFIG_MMIO_LENGTH, 0x1000, false);
> > >  	if (ret)
> > >  		return ret;
> > > --
> > > 2.43.0

RE: [PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window

[Matthew Ruffell]

Hi Michael,

> > I wonder if commit a41e0ab394e4 broke the initialization of screen_info in the
> > kdump kernel. Or perhaps there is now a rev-lock between the kernel with this
> > commit and a new version of the user space kexec command.

a41e0ab394e4 isn't a mainline commit. Can you please mention the commit subject
so I can have a read.

> > There's a parameter to the kexec() command that governs whether it uses the
> > kexec_file_load() system call or the kexec_load() system call.
> > I wonder if that parameter makes a difference in the problem described for this
> > patch.

Yes, it does indeed make a difference. I have been debugging this the past few
days, and my colleague Melissa noticed that the problem reproduces when secure
boot is disabled, but it does not reproduce when secure boot is enabled. 
Additionally, it reproduces on jammy, but not noble. It turns out that 
kexec-tools on jammy defaults to kexec_load() when secure boot is disabled,
and when enabled, it instead uses kexec_file_load(). On noble, it defaults to
first trying kexec_file_load() before falling back to kexec_load(), so the
issue does not reproduce.

> > >  	/*
> > >  	 * Set up a region of MMIO space to use for accessing configuration
> > > -	 * space.
> > > +	 * space. Use the high MMIO range to not conflict with the hyperv_drm
> > > +	 * driver (which normally gets MMIO from the low MMIO range) in the
> > > +	 * kdump kernel of a Gen2 VM, which fails to reserve the framebuffer
> > > +	 * MMIO range in vmbus_reserve_fb() due to screen_info.lfb_base being
> > > +	 * zero in the kdump kernel.
> > >  	 */
> > > -	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, 0, -1,
> > > +	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, SZ_4G, -1,
> > >  				  PCI_CONFIG_MMIO_LENGTH, 0x1000, false);
> > >  	if (ret)
> > >  		return ret;
> > > --

Thank you for the patch Dexuan.

This patch fixes the problem on Ubuntu 5.15, and 6.8 based kernels
booting V6 instance types on Azure with Gen 2 images.

Tested-by: Matthew Ruffell <matthew.ruffell@canonical.com>

Thanks,
Matthew

RE: [PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window

[Michael Kelley]

From: Matthew Ruffell <matthew.ruffell@canonical.com> Sent: Thursday, January 22, 2026 9:39 PM
> 
> Hi Michael,
> 
> > > I wonder if commit a41e0ab394e4 broke the initialization of screen_info in the
> > > kdump kernel. Or perhaps there is now a rev-lock between the kernel with this
> > > commit and a new version of the user space kexec command.
> 
> a41e0ab394e4 isn't a mainline commit. Can you please mention the commit subject
> so I can have a read.

It's this patch:

https://lore.kernel.org/lkml/20251126160854.553077-5-tzimmermann@suse.de/

which is in linux-next, but not yet in mainline. Since you are dealing with older
kernels, it's not the culprit.

> 
> > > There's a parameter to the kexec() command that governs whether it uses the
> > > kexec_file_load() system call or the kexec_load() system call.
> > > I wonder if that parameter makes a difference in the problem described for this
> > > patch.
> 
> Yes, it does indeed make a difference. I have been debugging this the past few
> days, and my colleague Melissa noticed that the problem reproduces when secure
> boot is disabled, but it does not reproduce when secure boot is enabled.
> Additionally, it reproduces on jammy, but not noble. It turns out that
> kexec-tools on jammy defaults to kexec_load() when secure boot is disabled,
> and when enabled, it instead uses kexec_file_load(). On noble, it defaults to
> first trying kexec_file_load() before falling back to kexec_load(), so the
> issue does not reproduce.

This is good info, and definitely a clue. So to be clear, the problem repros
only when kexec_load() is used. With kexec_file_load(), it does not repro. Is that
right? I saw a similar distinction when working on commit 304386373007,
though in the opposite direction!

> 
> > > >  	/*
> > > >  	 * Set up a region of MMIO space to use for accessing configuration
> > > > -	 * space.
> > > > +	 * space. Use the high MMIO range to not conflict with the hyperv_drm
> > > > +	 * driver (which normally gets MMIO from the low MMIO range) in the
> > > > +	 * kdump kernel of a Gen2 VM, which fails to reserve the framebuffer
> > > > +	 * MMIO range in vmbus_reserve_fb() due to screen_info.lfb_base being
> > > > +	 * zero in the kdump kernel.
> > > >  	 */
> > > > -	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, 0, -1,
> > > > +	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, SZ_4G, -1,
> > > >  				  PCI_CONFIG_MMIO_LENGTH, 0x1000, false);
> > > >  	if (ret)
> > > >  		return ret;
> > > > --
> 
> Thank you for the patch Dexuan.
> 
> This patch fixes the problem on Ubuntu 5.15, and 6.8 based kernels
> booting V6 instance types on Azure with Gen 2 images.

Are you seeing the problem on x86/64 or arm64 instances in Azure?
"V6 instance types" could be either, I think, but I'm guessing you
are on x86/64.

And just to confirm: are you seeing the problem with the
Hyper-V DRM driver, or the Hyper-V FB driver? This patch mentions
the DRM driver, so I assume that's the problematic config.

> 
> Tested-by: Matthew Ruffell <matthew.ruffell@canonical.com>

While this patch may solve the observed problem, I'm interested in
understanding the root cause of why vmbus_reserve_fb() is seeing
screen_info.lfb_base set to zero. It may be next week before I can
take a look, and I may need follow up with you on more details of the
scenario to reproduce the problem.

Michael

RE: [PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window

[Michael Kelley]

From: Michael Kelley <mhklinux@outlook.com> Sent: Thursday, January 22, 2026 10:39 PM
> 
> From: Matthew Ruffell <matthew.ruffell@canonical.com> Sent: Thursday, January 22, 2026 9:39 PM
> >
> > Hi Michael,
> >
> > > > I wonder if commit a41e0ab394e4 broke the initialization of screen_info in the
> > > > kdump kernel. Or perhaps there is now a rev-lock between the kernel with this
> > > > commit and a new version of the user space kexec command.
> >
> > a41e0ab394e4 isn't a mainline commit. Can you please mention the commit subject
> > so I can have a read.
> 
> It's this patch:
> 
> https://lore.kernel.org/lkml/20251126160854.553077-5-tzimmermann@suse.de/ 
> 
> which is in linux-next, but not yet in mainline. Since you are dealing with older
> kernels, it's not the culprit.
> 
> >
> > > > There's a parameter to the kexec() command that governs whether it uses the
> > > > kexec_file_load() system call or the kexec_load() system call.
> > > > I wonder if that parameter makes a difference in the problem described for this
> > > > patch.
> >
> > Yes, it does indeed make a difference. I have been debugging this the past few
> > days, and my colleague Melissa noticed that the problem reproduces when secure
> > boot is disabled, but it does not reproduce when secure boot is enabled.
> > Additionally, it reproduces on jammy, but not noble. It turns out that
> > kexec-tools on jammy defaults to kexec_load() when secure boot is disabled,
> > and when enabled, it instead uses kexec_file_load(). On noble, it defaults to
> > first trying kexec_file_load() before falling back to kexec_load(), so the
> > issue does not reproduce.
> 
> This is good info, and definitely a clue. So to be clear, the problem repros
> only when kexec_load() is used. With kexec_file_load(), it does not repro. Is that
> right? I saw a similar distinction when working on commit 304386373007,
> though in the opposite direction!
> 
> >
> > > > >  	/*
> > > > >  	 * Set up a region of MMIO space to use for accessing configuration
> > > > > -	 * space.
> > > > > +	 * space. Use the high MMIO range to not conflict with the hyperv_drm
> > > > > +	 * driver (which normally gets MMIO from the low MMIO range) in the
> > > > > +	 * kdump kernel of a Gen2 VM, which fails to reserve the framebuffer
> > > > > +	 * MMIO range in vmbus_reserve_fb() due to screen_info.lfb_base being
> > > > > +	 * zero in the kdump kernel.
> > > > >  	 */
> > > > > -	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, 0, -1,
> > > > > +	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, SZ_4G, -1,
> > > > >  				  PCI_CONFIG_MMIO_LENGTH, 0x1000, false);
> > > > >  	if (ret)
> > > > >  		return ret;
> > > > > --
> >
> > Thank you for the patch Dexuan.
> >
> > This patch fixes the problem on Ubuntu 5.15, and 6.8 based kernels
> > booting V6 instance types on Azure with Gen 2 images.
> 
> Are you seeing the problem on x86/64 or arm64 instances in Azure?
> "V6 instance types" could be either, I think, but I'm guessing you
> are on x86/64.
> 
> And just to confirm: are you seeing the problem with the
> Hyper-V DRM driver, or the Hyper-V FB driver? This patch mentions
> the DRM driver, so I assume that's the problematic config.
> 
> >
> > Tested-by: Matthew Ruffell <matthew.ruffell@canonical.com>
> 
> While this patch may solve the observed problem, I'm interested in
> understanding the root cause of why vmbus_reserve_fb() is seeing
> screen_info.lfb_base set to zero. It may be next week before I can
> take a look, and I may need follow up with you on more details of the
> scenario to reproduce the problem.

One more thought here: Is commit 96959283a58d relevant? The
commit message describes a scenario where vmbus_reserve_fb()
doesn't do anything because CONFIG_SYSFB is not set. Looking at
the code for vmbus_reserve_fb(), it doing nothing might imply that
screen_info.lfb_base is 0. But when CONFIG_SYSFB is not set,
screen_info.lfb_base is just ignored, with the same result. This behavior
started with the 6.7 kernel due to commit a07b50d80ab6.

Note that commit 96959283a58d has a follow-on to correct a
problem when CONFIG_EFI is not set.  See commit 7b89a44b2e8c.
If there's a reason to backport 96959283a58d, also get
7b89a44b2e8c.

Michael

RE: [PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window

[Dexuan Cui]

Thank you for all the good input! I'll do more research and report back.

Re: [PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window

[Krister Johansen]

Hi Matthew and Michael,

On Fri, Jan 23, 2026 at 06:39:24AM +0000, Michael Kelley wrote:
> From: Matthew Ruffell <matthew.ruffell@canonical.com> Sent: Thursday, January 22, 2026 9:39 PM
> > > > There's a parameter to the kexec() command that governs whether it uses the
> > > > kexec_file_load() system call or the kexec_load() system call.
> > > > I wonder if that parameter makes a difference in the problem described for this
> > > > patch.
> > 
> > Yes, it does indeed make a difference. I have been debugging this the past few
> > days, and my colleague Melissa noticed that the problem reproduces when secure
> > boot is disabled, but it does not reproduce when secure boot is enabled.
> > Additionally, it reproduces on jammy, but not noble. It turns out that
> > kexec-tools on jammy defaults to kexec_load() when secure boot is disabled,
> > and when enabled, it instead uses kexec_file_load(). On noble, it defaults to
> > first trying kexec_file_load() before falling back to kexec_load(), so the
> > issue does not reproduce.
> 
> This is good info, and definitely a clue. So to be clear, the problem repros
> only when kexec_load() is used. With kexec_file_load(), it does not repro. Is that
> right? I saw a similar distinction when working on commit 304386373007,
> though in the opposite direction!

Just to muddy the waters here, I have a team on the Noble 6.8 kernel
train that's running into this issue on Standard_D#pds_v6 with secure
boot disabled. I've validated via strace(8) that kexec(8) is calling
kexec_file_load(2), but in this case the problem Dexuan describes in the
cover letter occurs but affects NIC attachment instead of the NVMe
storage device. (e.g. pci_hyperv attach of the NIC reports the
pass-through error instead of successfully attaching).


> > > > >  	/*
> > > > >  	 * Set up a region of MMIO space to use for accessing configuration
> > > > > -	 * space.
> > > > > +	 * space. Use the high MMIO range to not conflict with the hyperv_drm
> > > > > +	 * driver (which normally gets MMIO from the low MMIO range) in the
> > > > > +	 * kdump kernel of a Gen2 VM, which fails to reserve the framebuffer
> > > > > +	 * MMIO range in vmbus_reserve_fb() due to screen_info.lfb_base being
> > > > > +	 * zero in the kdump kernel.
> > > > >  	 */
> > > > > -	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, 0, -1,
> > > > > +	ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, SZ_4G, -1,
> > > > >  				  PCI_CONFIG_MMIO_LENGTH, 0x1000, false);
> > > > >  	if (ret)
> > > > >  		return ret;
> > > > > --
> > 
> > Thank you for the patch Dexuan.
> > 
> > This patch fixes the problem on Ubuntu 5.15, and 6.8 based kernels
> > booting V6 instance types on Azure with Gen 2 images.
> 
> Are you seeing the problem on x86/64 or arm64 instances in Azure?
> "V6 instance types" could be either, I think, but I'm guessing you
> are on x86/64.
> 
> And just to confirm: are you seeing the problem with the
> Hyper-V DRM driver, or the Hyper-V FB driver? This patch mentions
> the DRM driver, so I assume that's the problematic config.

It's been arm64 and not x86 for the case I've seen.  They're currently
running with the hyperv_drm driver, but they've also tried swapping to
the fb driver without any change in results.

> > Tested-by: Matthew Ruffell <matthew.ruffell@canonical.com>

All of the above said, I also tested Dexuan's fix on these instances and
found that with the patch applied kdump did work again.

Tested-by: Krister Johansen <johansen@templeofstupid.com>

-K