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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.02.2026 10:14, Roger Pau Monné wrote:
> 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().

Less fragile - perhaps. Yet I don't see why we should populate the field if
we wouldn't ever need it. Of course with violating layering some, we could
know in subarch_init_memory(), as pci_setup() runs earlier.

Jan