Re: Kernel panic in __pci_enable_msix_range on Xen PV with PCI passthrough

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.08.2021 17:24, Marek Marczykowski-Górecki wrote:
> On recent kernel I get kernel panic when starting a Xen PV domain with
> PCI devices assigned. This happens on 5.10.60 (worked on .54) and
> 5.4.142 (worked on .136): 
> 
> [   13.683009] pcifront pci-0: claiming resource 0000:00:00.0/0
> [   13.683042] pcifront pci-0: claiming resource 0000:00:00.0/1
> [   13.683049] pcifront pci-0: claiming resource 0000:00:00.0/2
> [   13.683055] pcifront pci-0: claiming resource 0000:00:00.0/3
> [   13.683061] pcifront pci-0: claiming resource 0000:00:00.0/6
> [   14.036142] e1000e: Intel(R) PRO/1000 Network Driver
> [   14.036179] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
> [   14.036982] e1000e 0000:00:00.0: Xen PCI mapped GSI11 to IRQ13
> [   14.044561] e1000e 0000:00:00.0: Interrupt Throttling Rate (ints/sec) set 
> to dynamic conservative mode
> [   14.045188] BUG: unable to handle page fault for address: ffffc9004069100c
> [   14.045197] #PF: supervisor write access in kernel mode
> [   14.045202] #PF: error_code(0x0003) - permissions violation
> [   14.045211] PGD 18f1c067 P4D 18f1c067 PUD 4dbd067 PMD 4fba067 PTE 
> 80100000febd4075

I'm curious what lives at physical address FEBD4000. The maximum verbosity
hypervisor log may also have a hint as to why this is a read-only PTE.

> [   14.045227] Oops: 0003 [#1] SMP NOPTI
> [   14.045234] CPU: 0 PID: 234 Comm: kworker/0:2 Tainted: G        W         
> 5.14.0-rc7-1.fc32.qubes.x86_64 #15
> [   14.045245] Workqueue: events work_for_cpu_fn
> [   14.045259] RIP: e030:__pci_enable_msix_range.part.0+0x26b/0x5f0
> [   14.045271] Code: 2f 96 ff 48 89 44 24 28 48 89 c7 48 85 c0 0f 84 f6 01 00 
> 00 45 0f b7 f6 48 8d 40 0c ba 01 00 00 00 49 c1 e6 04 4a 8d 4c 37 1c <89> 10 
> 48 83 c0 10 48 39 c1 75 f5 41 0f b6 44 24 6a 84 c0 0f 84 48
> [   14.045284] RSP: e02b:ffffc9004018bd50 EFLAGS: 00010212
> [   14.045290] RAX: ffffc9004069100c RBX: ffff88800ed412f8 RCX: 
> ffffc9004069105c
> [   14.045296] RDX: 0000000000000001 RSI: 00000000000febd4 RDI: 
> ffffc90040691000
> [   14.045302] RBP: 0000000000000003 R08: 0000000000000000 R09: 
> 00000000febd404f
> [   14.045308] R10: 0000000000007ff0 R11: ffff88800ee8ae40 R12: 
> ffff88800ed41000
> [   14.045313] R13: 0000000000000000 R14: 0000000000000040 R15: 
> 00000000feba0000
> [   14.045393] FS:  0000000000000000(0000) GS:ffff888018400000(0000) 
> knlGS:0000000000000000
> [   14.045401] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   14.045407] CR2: ffff8000007f5ea0 CR3: 0000000012f6a000 CR4: 
> 0000000000000660
> [   14.045420] Call Trace:
> [   14.045431]  e1000e_set_interrupt_capability+0xbf/0xd0 [e1000e]
> [   14.045479]  e1000_probe+0x41f/0xdb0 [e1000e]

Otoh, from this it's pretty clear it's not a device Xen may have found
a need to access for its own purposes. If aforementioned address covers
(or is adjacent to) the MSI-X table of a device drive by this driver,
then it would also be helpful to know how many MSI-X entries the device
reports its table can have.

Jan

> [   14.045506]  local_pci_probe+0x42/0x80
> [   14.045515]  work_for_cpu_fn+0x16/0x20
> [   14.045522]  process_one_work+0x1ec/0x390
> [   14.045529]  worker_thread+0x53/0x3e0
> [   14.045534]  ? process_one_work+0x390/0x390
> [   14.045540]  kthread+0x127/0x150
> [   14.045548]  ? set_kthread_struct+0x40/0x40
> [   14.045554]  ret_from_fork+0x22/0x30
> [   14.045565] Modules linked in: e1000e(+) edac_mce_amd rfkill xen_pcifront 
> pcspkr xt_REDIRECT ip6table_filter ip6table_mangle ip6table_raw ip6_tables 
> ipt_REJECT nf_reject_ipv4 xt_state xt_conntrack iptable_filter iptable_mangle 
> iptable_raw xt_MASQUERADE iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 
> nf_defrag_ipv4 xen_scsiback target_core_mod xen_netback xen_privcmd 
> xen_gntdev xen_gntalloc xen_blkback xen_evtchn fuse drm bpf_preload ip_tables 
> overlay xen_blkfront
> [   14.045620] CR2: ffffc9004069100c
> [   14.045627] ---[ end trace 307f5bb3bd9f30b4 ]---
> [   14.045632] RIP: e030:__pci_enable_msix_range.part.0+0x26b/0x5f0
> [   14.045640] Code: 2f 96 ff 48 89 44 24 28 48 89 c7 48 85 c0 0f 84 f6 01 00 
> 00 45 0f b7 f6 48 8d 40 0c ba 01 00 00 00 49 c1 e6 04 4a 8d 4c 37 1c <89> 10 
> 48 83 c0 10 48 39 c1 75 f5 41 0f b6 44 24 6a 84 c0 0f 84 48
> [   14.045652] RSP: e02b:ffffc9004018bd50 EFLAGS: 00010212
> [   14.045657] RAX: ffffc9004069100c RBX: ffff88800ed412f8 RCX: 
> ffffc9004069105c
> [   14.045663] RDX: 0000000000000001 RSI: 00000000000febd4 RDI: 
> ffffc90040691000
> [   14.045668] RBP: 0000000000000003 R08: 0000000000000000 R09: 
> 00000000febd404f
> [   14.045674] R10: 0000000000007ff0 R11: ffff88800ee8ae40 R12: 
> ffff88800ed41000
> [   14.045679] R13: 0000000000000000 R14: 0000000000000040 R15: 
> 00000000feba0000
> [   14.045698] FS:  0000000000000000(0000) GS:ffff888018400000(0000) 
> knlGS:0000000000000000
> [   14.045706] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   14.045711] CR2: ffff8000007f5ea0 CR3: 0000000012f6a000 CR4: 
> 0000000000000660
> [   14.045718] Kernel panic - not syncing: Fatal exception
> [   14.045726] Kernel Offset: disabled
> 
> I've bisected it down to this commit:
> 
>     commit 7d5ec3d3612396dc6d4b76366d20ab9fc06f399f
>     Author: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
>     Date:   Thu Jul 29 23:51:41 2021 +0200
> 
>         PCI/MSI: Mask all unused MSI-X entries
> 
> I can reliably reproduce it on Xen 4.14 and Xen 4.8, so I don't think
> Xen version matters here.
> 
> Any idea how to fix it?
>