linux-kernel - Re: xen pci passthrough stops working after xen/x86: fix initial memory balloon target

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aWjXpepx2T6wy5uq@Mac.lan>
Date: Thu, 15 Jan 2026 13:03:49 +0100
From: Roger Pau Monné <roger.pau@...rix.com>
To: James Dingwall <james@...gwall.me.uk>
Cc: linux-kernel@...r.kernel.org
Subject: Re: xen pci passthrough stops working after xen/x86: fix initial
 memory balloon target

On Thu, Jan 15, 2026 at 11:23:37AM +0000, James Dingwall wrote:
> Hi,
> 
> We have encountered a regression with pci passthrough since the
> Ubuntu 6.8.0-91.92 which included this commit:

Hello,

Thanks for the report.  Could you also send me your kernel Kconfig, to
see which combination of options are you using?

> commit 74287971dbb3fe322bb316afd9e7fb5807e23bee
> Author: Roger Pau Monne <roger.pau@...rix.com>
> Date:   Wed May 14 10:04:26 2025 +0200
> 
>     xen/x86: fix initial memory balloon target
> 
> The problem also happens with a 6.19-rc5 build so doesn't seem to be specific
> to the Ubuntu kernel.  We deploy an identical disk image to multiple systems
> but only one hardware model shows this error and I'm not certain what the
> significant difference is.  Logs associated with one of the pci devices:
> 
> non-working 6.19-rc5 build:
> 
> # grep 01:00.0 6.19.0-061900rc5-generic.log
> Jan 15 10:32:21 pci 0000:01:00.0: [8086:1521] type 00 class 0x020000 PCIe Endpoint
> Jan 15 10:32:21 pci 0000:01:00.0: BAR 0 [mem 0x81200000-0x812fffff]
> Jan 15 10:32:21 pci 0000:01:00.0: BAR 2 [io 0x4020-0x403f]
> Jan 15 10:32:21 pci 0000:01:00.0: BAR 3 [mem 0x81404000-0x81407fff]
> Jan 15 10:32:21 pci 0000:01:00.0: ROM [mem 0x81380000-0x813fffff pref]
> Jan 15 10:32:21 pci 0000:01:00.0: VF BAR 0 [mem 0x4000200000-0x4000203fff 64bit pref]
> Jan 15 10:32:21 pci 0000:01:00.0: VF BAR 0 [mem 0x4000200000-0x400021ffff 64bit pref]: contains BAR 0 for 8 VFs
> Jan 15 10:32:21 pci 0000:01:00.0: VF BAR 3 [mem 0x4000220000-0x4000223fff 64bit pref]
> Jan 15 10:32:21 pci 0000:01:00.0: VF BAR 3 [mem 0x4000220000-0x400023ffff 64bit pref]: contains BAR 3 for 8 VFs
> Jan 15 10:32:21 pcifront pci-0: claiming resource 0000:01:00.0/0
> Jan 15 10:32:21 pci 0000:01:00.0: BAR 0 [mem 0x81200000-0x812fffff]: can't claim; address conflict with System RAM [mem 0x80000000-0x87ffffff]
> Jan 15 10:32:21 pcifront pci-0: Could not claim resource 0000:01:00.0/0! Device offline. Try using e820_host=1 in the guest config.
> Jan 15 10:32:21 pcifront pci-0: claiming resource 0000:01:00.0/2
> Jan 15 10:32:21 pcifront pci-0: claiming resource 0000:01:00.0/3
> Jan 15 10:32:21 pci 0000:01:00.0: BAR 3 [mem 0x81404000-0x81407fff]: can't claim; address conflict with System RAM [mem 0x80000000-0x87ffffff]
> Jan 15 10:32:21 pcifront pci-0: Could not claim resource 0000:01:00.0/3! Device offline. Try using e820_host=1 in the guest config.
> Jan 15 10:32:21 pcifront pci-0: claiming resource 0000:01:00.0/6
> Jan 15 10:32:21 pci 0000:01:00.0: ROM [mem 0x81380000-0x813fffff pref]: can't claim; address conflict with System RAM [mem 0x80000000-0x87ffffff]
> Jan 15 10:32:21 pcifront pci-0: Could not claim resource 0000:01:00.0/6! Device offline. Try using e820_host=1 in the guest config.
> Jan 15 10:32:21 pcifront pci-0: claiming resource 0000:01:00.0/7
> Jan 15 10:32:21 pcifront pci-0: claiming resource 0000:01:00.0/10
> Jan 15 10:32:21 igb 0000:01:00.0: BAR 0 [mem size 0x00100000]: not assigned; can't enable device
> Jan 15 10:32:21 igb 0000:01:00.0: probe with driver igb failed with error -22

AFAICT it's quite likely that the balloon driver / unpopulated alloc
has instantiated a hotplug memory region over the space used by the
device, ahead of the device being initialized and having claimed the
region for itself.

I'm not sure exactly how that's tied to the commit above, will know
more with the Kconfig.

Thanks, Roger.