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
