Re: [PATCH v3 5/6] x86/PCI: avoid re-evaluation of extended config space accessibility

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.