On Mon, Feb 02, 2026 at 09:51:18AM +0100, Jan Beulich wrote:
> On 29.01.2026 14:10, Jan Beulich wrote:
> > @@ -160,10 +161,13 @@ int pci_mmcfg_arch_enable(unsigned int i
> > return 0;
> > }
> >
> > -void pci_mmcfg_arch_disable(unsigned int idx)
> > +int pci_mmcfg_arch_disable(unsigned int idx)
> > {
> > const typeof(pci_mmcfg_config[0]) *cfg = pci_mmcfg_virt[idx].cfg;
> >
> > + if ( !pci_mmcfg_virt[idx].virt )
> > + return 1;
>
> Afaict this is what causes CI (adl-*) to say no here:
>
> (XEN) [ 4.132689] PCI: Using MCFG for segment 0000 bus 00-ff
> (XEN) [ 4.132697] ----[ Xen-4.22-unstable x86_64 debug=y ubsan=y Not
> tainted ]----
> (XEN) [ 4.132700] CPU: 12
> (XEN) [ 4.132702] RIP: e008:[<ffff82d0405779bd>]
> pci_mmcfg_read+0x19e/0x1c7
> (XEN) [ 4.132708] RFLAGS: 0000000000010286 CONTEXT: hypervisor (d0v0)
> (XEN) [ 4.132711] rax: 0000000000300000 rbx: ffff808000300100 rcx:
> 0000000000000000
> (XEN) [ 4.132714] rdx: ffff808000300100 rsi: 0000000000000000 rdi:
> ffff8304959ffcec
> (XEN) [ 4.132716] rbp: ffff8304959ffd18 rsp: ffff8304959ffce8 r8:
> 0000000000000004
> (XEN) [ 4.132718] r9: ffff8304959ffd2c r10: 0000000000000000 r11:
> 0000000000000000
> (XEN) [ 4.132720] r12: 0000000000000100 r13: 0000000000000004 r14:
> ffff8304959ffd2c
> (XEN) [ 4.132723] r15: ffff808000000000 cr0: 0000000080050033 cr4:
> 0000000000b526e0
> (XEN) [ 4.132725] cr3: 0000000492a30000 cr2: ffff808000300100
> (XEN) [ 4.132727] fsb: 0000000000000000 gsb: ffff8881b9a00000 gss:
> 0000000000000000
> (XEN) [ 4.132729] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010
> cs: e008
> (XEN) [ 4.132733] Xen code around <ffff82d0405779bd>
> (pci_mmcfg_read+0x19e/0x1c7):
> (XEN) [ 4.132734] 48 39 d3 72 ea 4c 01 e3 <8b> 03 89 c3 4d 85 f6 74 0d 41
> 89 1e b8 00 00 00
> (XEN) [ 4.132744] Xen stack trace from rsp=ffff8304959ffce8:
> (XEN) [ 4.132745] 0000000300000286 ffff830495bd8010 0000000000000003
> ffff830495bd8010
> (XEN) [ 4.132749] ffff8304959ffdd0 ffff82d0405fa7ef ffff8304959ffd30
> ffff82d040576877
> (XEN) [ 4.132753] 000000000000000c ffff8304959ffd58 ffff82d04039b81d
> ffff8304959ffe28
> (XEN) [ 4.132756] 0000000000000003 ffff830495bd8010 ffff8304959ffd80
> ffff82d0405fa90b
> (XEN) [ 4.132760] ffff8304959ffdc8 ffff830495bd8010 ffff830498019650
> ffff8304959ffdb8
> (XEN) [ 4.132764] ffff82d0403983e0 ffff830498019650 ffff8304959ffe28
> ffff82d0405fa7ef
> (XEN) [ 4.132767] 0000000000000018 ffffc9004002b900 ffff8304959ffdf8
> ffff82d04039feba
> (XEN) [ 4.132771] ffff82d0405fa7ef ffff8304959ffe28 0000000000000000
> ffffc9004002b900
> (XEN) [ 4.132774] 0000000000000000 ffff8304959bb000 ffff8304959ffe78
> ffff82d0405ff666
> (XEN) [ 4.132778] ffff82d0405713b8 00000000ffffffff 00a0fb0081f456e0
> ffff8304959b3010
> (XEN) [ 4.132782] 00000000c0000000 00000001ff000000 ffff8304959fff08
> 0000000000000040
> (XEN) [ 4.132785] 000000ec00000001 ffff8304959fff08 ffff8304959a4000
> 0000000000000021
> (XEN) [ 4.132789] 0000000000000000 ffffc9004002b900 ffff8304959ffef8
> ffff82d0405711b2
> (XEN) [ 4.132792] 0000000000000000 ffff888100456938 ffff8881001470b8
> 0000000000000018
> (XEN) [ 4.132795] 0000000000000000 ffff8304959ffef8 ffff82d0406213f9
> ffff8304959a4000
> (XEN) [ 4.132799] 0000000000000000 ffff8304959a4000 0000000000000000
> 0000000000000000
> (XEN) [ 4.132802] ffff8304959fffff 0000000000000000 00007cfb6a6000d7
> ffff82d0402012d3
> (XEN) [ 4.132806] 0000000000000000 00000000ffffffff ffff8881001470b8
> ffff888100b88900
> (XEN) [ 4.132809] ffffc9004002b900 ffff8881001470b8 0000000000000283
> ffff888100456938
> (XEN) [ 4.132813] ffff888100065410 0000000000000000 0000000000000021
> ffffffff81f7842a
> (XEN) [ 4.132816] Xen call trace:
> (XEN) [ 4.132819] [<ffff82d0405779bd>] R pci_mmcfg_read+0x19e/0x1c7
> (XEN) [ 4.132822] [<ffff82d040576877>] F pci_conf_read32+0x55/0x5e
> (XEN) [ 4.132826] [<ffff82d04039b81d>] F pci_check_extcfg+0xb1/0x13b
> (XEN) [ 4.132831] [<ffff82d0405fa90b>] F
> physdev_check_pci_extcfg+0x11c/0x121
> (XEN) [ 4.132833] [<ffff82d0403983e0>] F
> drivers/passthrough/pci.c#iterate_all+0xa2/0xe2
> (XEN) [ 4.132836] [<ffff82d04039feba>] F pci_segment_iterate+0x4e/0x74
> (XEN) [ 4.132839] [<ffff82d0405ff666>] F do_physdev_op+0x362a/0x4161
> (XEN) [ 4.132842] [<ffff82d0405711b2>] F pv_hypercall+0x6be/0x838
> (XEN) [ 4.132845] [<ffff82d0402012d3>] F lstar_enter+0x143/0x148
> (XEN) [ 4.132847]
> (XEN) [ 4.132848] Pagetable walk from ffff808000300100:
> (XEN) [ 4.132851] L4[0x101] = 0000000000000000 ffffffffffffffff
>
> There is an important comment in pci_mmcfg_arch_disable():
>
> /*
> * Don't use destroy_xen_mappings() here, or make sure that at least
> * the necessary L4 entries get populated (so that they get properly
> * propagated to guest domains' page tables).
> */
>
> Hence it is wrong to bypass
>
> mcfg_ioremap(cfg, idx, 0);
Hm, I see. The L4 slot must be unconditionally populated before we
clone the idle page-table, otherwise the mappings won't propagate.
What about unconditionally populating the L4 slot in
subarch_init_memory()? That seems less fragile than doing it in
pci_mmcfg_arch_disable().
Thanks, Roger.
