* xen-unstable linux-5.14: 1 of 2 multicall(s) failed: cpu 0
@ 2021-09-06 21:35 Sander Eikelenboom
2021-09-07 6:54 ` Jan Beulich
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Sander Eikelenboom @ 2021-09-06 21:35 UTC (permalink / raw)
To: xen-devel
L.S.,
On my AMD box running:
xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
linux kernel: 5.14.1
With this setup I'm encountering some issues in dom0, see below.
--
Sander
xl dmesg gives:
(XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 63b936 already pinned
(XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a0622 already pinned
(XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6b63da already pinned
(XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 638dd9 already pinned
(XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 68a7bc already pinned
(XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 63c27d already pinned
(XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a04f2 already pinned
(XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 690d49 already pinned
(XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6959a0 already pinned
(XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a055e already pinned
(XEN) [2021-09-06 18:15:04.090] mm.c:3506:d0v0 mfn 639437 already pinned
dmesg gives:
[34321.304270] ------------[ cut here ]------------
[34321.304277] WARNING: CPU: 0 PID: 23628 at arch/x86/xen/multicalls.c:102 xen_mc_flush+0x176/0x1a0
[34321.304288] Modules linked in:
[34321.304291] CPU: 0 PID: 23628 Comm: apt-get Not tainted 5.14.1-20210906-doflr-mac80211debug+ #1
[34321.304294] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010
[34321.304296] RIP: e030:xen_mc_flush+0x176/0x1a0
[34321.304300] Code: 89 45 18 48 c1 e9 3f 48 89 ce e9 20 ff ff ff e8 60 03 00 00 66 90 5b 5d 41 5c 41 5d c3 48 c7 45 18 ea ff ff ff be 01 00 00 00 <0f> 0b 8b 55 00 48 c7 c7 10 97 aa 82 31 db 49 c7 c5 38 97 aa 82 65
[34321.304303] RSP: e02b:ffffc90000a97c90 EFLAGS: 00010002
[34321.304305] RAX: ffff88807d416398 RBX: ffff88807d416350 RCX: ffff88807d416398
[34321.304306] RDX: 0000000000000001 RSI: 0000000000000001 RDI: deadbeefdeadf00d
[34321.304308] RBP: ffff88807d416300 R08: aaaaaaaaaaaaaaaa R09: ffff888006160cc0
[34321.304309] R10: deadbeefdeadf00d R11: ffffea000026a600 R12: 0000000000000000
[34321.304310] R13: ffff888012f6b000 R14: 0000000012f6b000 R15: 0000000000000001
[34321.304320] FS: 00007f5071177800(0000) GS:ffff88807d400000(0000) knlGS:0000000000000000
[34321.304322] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[34321.304323] CR2: 00007f506f542000 CR3: 00000000160cc000 CR4: 0000000000000660
[34321.304326] Call Trace:
[34321.304331] xen_alloc_pte+0x294/0x320
[34321.304334] move_pgt_entry+0x165/0x4b0
[34321.304339] move_page_tables+0x6fa/0x8d0
[34321.304342] move_vma.isra.44+0x138/0x500
[34321.304345] __x64_sys_mremap+0x296/0x410
[34321.304348] do_syscall_64+0x3a/0x80
[34321.304352] entry_SYSCALL_64_after_hwframe+0x44/0xae
[34321.304355] RIP: 0033:0x7f507196301a
[34321.304358] Code: 73 01 c3 48 8b 0d 76 0e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 19 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 46 0e 0c 00 f7 d8 64 89 01 48
[34321.304360] RSP: 002b:00007ffda1eecd38 EFLAGS: 00000246 ORIG_RAX: 0000000000000019
[34321.304362] RAX: ffffffffffffffda RBX: 000056205f950f30 RCX: 00007f507196301a
[34321.304363] RDX: 0000000001a00000 RSI: 0000000001900000 RDI: 00007f506dc56000
[34321.304364] RBP: 0000000001a00000 R08: 0000000000000010 R09: 0000000000000004
[34321.304365] R10: 0000000000000001 R11: 0000000000000246 R12: 00007f506dc56060
[34321.304367] R13: 00007f506dc56000 R14: 00007f506dc56060 R15: 000056205f950f30
[34321.304368] ---[ end trace a19885b78fe8f33e ]---
[34321.304370] 1 of 2 multicall(s) failed: cpu 0
[34321.304371] call 2: op=12297829382473034410 arg=[aaaaaaaaaaaaaaaa] result=-22
[34321.304398] ------------[ cut here ]------------
[34321.304399] WARNING: CPU: 0 PID: 23628 at arch/x86/xen/multicalls.c:102 xen_mc_flush+0x176/0x1a0
[34321.304403] Modules linked in:
[34321.304404] CPU: 0 PID: 23628 Comm: apt-get Tainted: G W 5.14.1-20210906-doflr-mac80211debug+ #1
[34321.304406] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010
[34321.304407] RIP: e030:xen_mc_flush+0x176/0x1a0
[34321.304410] Code: 89 45 18 48 c1 e9 3f 48 89 ce e9 20 ff ff ff e8 60 03 00 00 66 90 5b 5d 41 5c 41 5d c3 48 c7 45 18 ea ff ff ff be 01 00 00 00 <0f> 0b 8b 55 00 48 c7 c7 10 97 aa 82 31 db 49 c7 c5 38 97 aa 82 65
[34321.304411] RSP: e02b:ffffc90000a97c90 EFLAGS: 00010002
[34321.304413] RAX: ffff88807d416398 RBX: ffff88807d416350 RCX: ffff88807d416398
[34321.304414] RDX: 0000000000000001 RSI: 0000000000000001 RDI: deadbeefdeadf00d
[34321.304415] RBP: ffff88807d416300 R08: aaaaaaaaaaaaaaaa R09: ffff888006160cc0
[34321.304417] R10: deadbeefdeadf00d R11: ffffc90000a97ab8 R12: 0000000000000000
[34321.304418] R13: ffff888009e6a000 R14: 0000000009e6a000 R15: 0000000000000001
[34321.304422] FS: 00007f5071177800(0000) GS:ffff88807d400000(0000) knlGS:0000000000000000
[34321.304423] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[34321.304425] CR2: 00007f506f542000 CR3: 00000000160cc000 CR4: 0000000000000660
[34321.304427] Call Trace:
[34321.304428] xen_alloc_pte+0x294/0x320
[34321.304431] move_pgt_entry+0x165/0x4b0
[34321.304433] move_page_tables+0x6fa/0x8d0
[34321.304436] move_vma.isra.44+0x138/0x500
[34321.304439] __x64_sys_mremap+0x296/0x410
[34321.304442] do_syscall_64+0x3a/0x80
[34321.304444] entry_SYSCALL_64_after_hwframe+0x44/0xae
[34321.304446] RIP: 0033:0x7f507196301a
[34321.304448] Code: 73 01 c3 48 8b 0d 76 0e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 19 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 46 0e 0c 00 f7 d8 64 89 01 48
[34321.304449] RSP: 002b:00007ffda1eecd38 EFLAGS: 00000246 ORIG_RAX: 0000000000000019
[34321.304451] RAX: ffffffffffffffda RBX: 000056205f950f30 RCX: 00007f507196301a
[34321.304452] RDX: 0000000001a00000 RSI: 0000000001900000 RDI: 00007f506dc56000
[34321.304453] RBP: 0000000001a00000 R08: 0000000000000010 R09: 0000000000000004
[34321.304455] R10: 0000000000000001 R11: 0000000000000246 R12: 00007f506dc56060
[34321.304456] R13: 00007f506dc56000 R14: 00007f506dc56060 R15: 000056205f950f30
[34321.304457] ---[ end trace a19885b78fe8f33f ]---
[34321.304458] 1 of 2 multicall(s) failed: cpu 0
[34321.304459] call 2: op=12297829382473034410 arg=[aaaaaaaaaaaaaaaa] result=-22
[34321.304477] ------------[ cut here ]------------
[34321.304478] WARNING: CPU: 0 PID: 23628 at arch/x86/xen/multicalls.c:102 xen_mc_flush+0x176/0x1a0
[34321.304482] Modules linked in:
[34321.304483] CPU: 0 PID: 23628 Comm: apt-get Tainted: G W 5.14.1-20210906-doflr-mac80211debug+ #1
[34321.304485] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010
[34321.304486] RIP: e030:xen_mc_flush+0x176/0x1a0
[34321.304488] Code: 89 45 18 48 c1 e9 3f 48 89 ce e9 20 ff ff ff e8 60 03 00 00 66 90 5b 5d 41 5c 41 5d c3 48 c7 45 18 ea ff ff ff be 01 00 00 00 <0f> 0b 8b 55 00 48 c7 c7 10 97 aa 82 31 db 49 c7 c5 38 97 aa 82 65
[34321.304490] RSP: e02b:ffffc90000a97c90 EFLAGS: 00010002
[34321.304491] RAX: ffff88807d416398 RBX: ffff88807d416350 RCX: ffff88807d416398
[34321.304493] RDX: 0000000000000001 RSI: 0000000000000001 RDI: deadbeefdeadf00d
[34321.304494] RBP: ffff88807d416300 R08: aaaaaaaaaaaaaaaa R09: ffff888006160cc0
[34321.304495] R10: deadbeefdeadf00d R11: ffffc90000a97ab8 R12: 0000000000000000
[34321.304496] R13: ffff88801833e000 R14: 000000001833e000 R15: 0000000000000001
[34321.304500] FS: 00007f5071177800(0000) GS:ffff88807d400000(0000) knlGS:0000000000000000
[34321.304502] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[34321.304503] CR2: 00007f506f542000 CR3: 00000000160cc000 CR4: 0000000000000660
[34321.304505] Call Trace:
[34321.304506] xen_alloc_pte+0x294/0x320
[34321.304509] move_pgt_entry+0x165/0x4b0
[34321.304511] move_page_tables+0x6fa/0x8d0
[34321.304514] move_vma.isra.44+0x138/0x500
[34321.304516] __x64_sys_mremap+0x296/0x410
[34321.304519] do_syscall_64+0x3a/0x80
[34321.304521] entry_SYSCALL_64_after_hwframe+0x44/0xae
[34321.304523] RIP: 0033:0x7f507196301a
[34321.304525] Code: 73 01 c3 48 8b 0d 76 0e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 19 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 46 0e 0c 00 f7 d8 64 89 01 48
[34321.304526] RSP: 002b:00007ffda1eecd38 EFLAGS: 00000246 ORIG_RAX: 0000000000000019
[34321.304528] RAX: ffffffffffffffda RBX: 000056205f950f30 RCX: 00007f507196301a
[34321.304529] RDX: 0000000001a00000 RSI: 0000000001900000 RDI: 00007f506dc56000
[34321.304530] RBP: 0000000001a00000 R08: 0000000000000010 R09: 0000000000000004
[34321.304531] R10: 0000000000000001 R11: 0000000000000246 R12: 00007f506dc56060
[34321.304533] R13: 00007f506dc56000 R14: 00007f506dc56060 R15: 000056205f950f30
[34321.304534] ---[ end trace a19885b78fe8f340 ]---
[34321.304535] 1 of 2 multicall(s) failed: cpu 0
[34321.304536] call 2: op=12297829382473034410 arg=[aaaaaaaaaaaaaaaa] result=-22
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xen-unstable linux-5.14: 1 of 2 multicall(s) failed: cpu 0
2021-09-06 21:35 xen-unstable linux-5.14: 1 of 2 multicall(s) failed: cpu 0 Sander Eikelenboom
@ 2021-09-07 6:54 ` Jan Beulich
2021-09-07 7:58 ` Juergen Gross
2021-09-07 13:53 ` Juergen Gross
2 siblings, 0 replies; 8+ messages in thread
From: Jan Beulich @ 2021-09-07 6:54 UTC (permalink / raw)
To: Sander Eikelenboom; +Cc: xen-devel
On 06.09.2021 23:35, Sander Eikelenboom wrote:
> L.S.,
>
> On my AMD box running:
> xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
> linux kernel: 5.14.1
>
> With this setup I'm encountering some issues in dom0, see below.
Any indication as to "since when"? Xen update, kernel update, config
change, ...?
> xl dmesg gives:
>
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 63b936 already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a0622 already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6b63da already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 638dd9 already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 68a7bc already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 63c27d already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a04f2 already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 690d49 already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6959a0 already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a055e already pinned
> (XEN) [2021-09-06 18:15:04.090] mm.c:3506:d0v0 mfn 639437 already pinned
This hints more towards a kernel issue, but I wouldn't outright exclude
other reasons.
> dmesg gives:
>
> [34321.304270] ------------[ cut here ]------------
> [34321.304277] WARNING: CPU: 0 PID: 23628 at arch/x86/xen/multicalls.c:102 xen_mc_flush+0x176/0x1a0
> [34321.304288] Modules linked in:
> [34321.304291] CPU: 0 PID: 23628 Comm: apt-get Not tainted 5.14.1-20210906-doflr-mac80211debug+ #1
> [34321.304294] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010
> [34321.304296] RIP: e030:xen_mc_flush+0x176/0x1a0
> [34321.304300] Code: 89 45 18 48 c1 e9 3f 48 89 ce e9 20 ff ff ff e8 60 03 00 00 66 90 5b 5d 41 5c 41 5d c3 48 c7 45 18 ea ff ff ff be 01 00 00 00 <0f> 0b 8b 55 00 48 c7 c7 10 97 aa 82 31 db 49 c7 c5 38 97 aa 82 65
> [34321.304303] RSP: e02b:ffffc90000a97c90 EFLAGS: 00010002
> [34321.304305] RAX: ffff88807d416398 RBX: ffff88807d416350 RCX: ffff88807d416398
> [34321.304306] RDX: 0000000000000001 RSI: 0000000000000001 RDI: deadbeefdeadf00d
> [34321.304308] RBP: ffff88807d416300 R08: aaaaaaaaaaaaaaaa R09: ffff888006160cc0
> [34321.304309] R10: deadbeefdeadf00d R11: ffffea000026a600 R12: 0000000000000000
> [34321.304310] R13: ffff888012f6b000 R14: 0000000012f6b000 R15: 0000000000000001
> [34321.304320] FS: 00007f5071177800(0000) GS:ffff88807d400000(0000) knlGS:0000000000000000
> [34321.304322] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
> [34321.304323] CR2: 00007f506f542000 CR3: 00000000160cc000 CR4: 0000000000000660
> [34321.304326] Call Trace:
> [34321.304331] xen_alloc_pte+0x294/0x320
> [34321.304334] move_pgt_entry+0x165/0x4b0
> [34321.304339] move_page_tables+0x6fa/0x8d0
> [34321.304342] move_vma.isra.44+0x138/0x500
> [34321.304345] __x64_sys_mremap+0x296/0x410
> [34321.304348] do_syscall_64+0x3a/0x80
> [34321.304352] entry_SYSCALL_64_after_hwframe+0x44/0xae
> [34321.304355] RIP: 0033:0x7f507196301a
> [34321.304358] Code: 73 01 c3 48 8b 0d 76 0e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 19 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 46 0e 0c 00 f7 d8 64 89 01 48
> [34321.304360] RSP: 002b:00007ffda1eecd38 EFLAGS: 00000246 ORIG_RAX: 0000000000000019
> [34321.304362] RAX: ffffffffffffffda RBX: 000056205f950f30 RCX: 00007f507196301a
> [34321.304363] RDX: 0000000001a00000 RSI: 0000000001900000 RDI: 00007f506dc56000
> [34321.304364] RBP: 0000000001a00000 R08: 0000000000000010 R09: 0000000000000004
> [34321.304365] R10: 0000000000000001 R11: 0000000000000246 R12: 00007f506dc56060
> [34321.304367] R13: 00007f506dc56000 R14: 00007f506dc56060 R15: 000056205f950f30
> [34321.304368] ---[ end trace a19885b78fe8f33e ]---
> [34321.304370] 1 of 2 multicall(s) failed: cpu 0
> [34321.304371] call 2: op=12297829382473034410 arg=[aaaaaaaaaaaaaaaa] result=-22
Just as an observation: This (decimal) output of course isn't very helpful
for investigating issues like this one. But the 0xAA pattern indicates
anyway that what is being logged has been clobbered by the hypervisor.
For the output to be useful, MC_DEBUG needs to be enabled in the sources.
Jan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xen-unstable linux-5.14: 1 of 2 multicall(s) failed: cpu 0
2021-09-06 21:35 xen-unstable linux-5.14: 1 of 2 multicall(s) failed: cpu 0 Sander Eikelenboom
2021-09-07 6:54 ` Jan Beulich
@ 2021-09-07 7:58 ` Juergen Gross
2021-09-07 8:11 ` Jan Beulich
2021-09-07 13:53 ` Juergen Gross
2 siblings, 1 reply; 8+ messages in thread
From: Juergen Gross @ 2021-09-07 7:58 UTC (permalink / raw)
To: Sander Eikelenboom, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 4446 bytes --]
On 06.09.21 23:35, Sander Eikelenboom wrote:
> L.S.,
>
> On my AMD box running:
> xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
> linux kernel: 5.14.1
>
> With this setup I'm encountering some issues in dom0, see below.
>
> --
> Sander
>
> xl dmesg gives:
>
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 63b936 already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a0622 already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6b63da already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 638dd9 already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 68a7bc already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 63c27d already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a04f2 already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 690d49 already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6959a0 already pinned
> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a055e already pinned
> (XEN) [2021-09-06 18:15:04.090] mm.c:3506:d0v0 mfn 639437 already pinned
>
>
> dmesg gives:
>
> [34321.304270] ------------[ cut here ]------------
> [34321.304277] WARNING: CPU: 0 PID: 23628 at
> arch/x86/xen/multicalls.c:102 xen_mc_flush+0x176/0x1a0
> [34321.304288] Modules linked in:
> [34321.304291] CPU: 0 PID: 23628 Comm: apt-get Not tainted
> 5.14.1-20210906-doflr-mac80211debug+ #1
> [34321.304294] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
> V1.8B1 09/13/2010
> [34321.304296] RIP: e030:xen_mc_flush+0x176/0x1a0
> [34321.304300] Code: 89 45 18 48 c1 e9 3f 48 89 ce e9 20 ff ff ff e8 60
> 03 00 00 66 90 5b 5d 41 5c 41 5d c3 48 c7 45 18 ea ff ff ff be 01 00 00
> 00 <0f> 0b 8b 55 00 48 c7 c7 10 97 aa 82 31 db 49 c7 c5 38 97 aa 82 65
> [34321.304303] RSP: e02b:ffffc90000a97c90 EFLAGS: 00010002
> [34321.304305] RAX: ffff88807d416398 RBX: ffff88807d416350 RCX:
> ffff88807d416398
> [34321.304306] RDX: 0000000000000001 RSI: 0000000000000001 RDI:
> deadbeefdeadf00d
> [34321.304308] RBP: ffff88807d416300 R08: aaaaaaaaaaaaaaaa R09:
> ffff888006160cc0
> [34321.304309] R10: deadbeefdeadf00d R11: ffffea000026a600 R12:
> 0000000000000000
> [34321.304310] R13: ffff888012f6b000 R14: 0000000012f6b000 R15:
> 0000000000000001
> [34321.304320] FS: 00007f5071177800(0000) GS:ffff88807d400000(0000)
> knlGS:0000000000000000
> [34321.304322] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
> [34321.304323] CR2: 00007f506f542000 CR3: 00000000160cc000 CR4:
> 0000000000000660
> [34321.304326] Call Trace:
> [34321.304331] xen_alloc_pte+0x294/0x320
> [34321.304334] move_pgt_entry+0x165/0x4b0
> [34321.304339] move_page_tables+0x6fa/0x8d0
> [34321.304342] move_vma.isra.44+0x138/0x500
> [34321.304345] __x64_sys_mremap+0x296/0x410
> [34321.304348] do_syscall_64+0x3a/0x80
> [34321.304352] entry_SYSCALL_64_after_hwframe+0x44/0xae
> [34321.304355] RIP: 0033:0x7f507196301a
I can see why this failure is occurring, but I'm not sure which way is
the best to fix it.
The problem is that a pinned page table is moved: the pmd entry
referencing it is cleared and a new reference is put into the pmd.
This is done by getting the old pmd entry, clearing that entry, and then
using pmd_populate() to write the new pmd entry. pmd_populate() will
lead to a call of xen_pte_alloc() trying to pin the referenced page
table, which is failing, as it is already pinned.
The problem has been introduced by commit 0881ace292b662d2 in kernel
5.14.
Following solutions would be possible:
1. When running as PV guest skip the optimization of move_pgt_entry()
by letting arch_supports_page_table_move() return false. This will
result in a performance drop in some cases.
2. Unpin the page table before calling pmd_populate(). This adds some
unneeded hypercall and without flushing the TLB I'm feeling uneasy
to do that.
3. Add a check in xen_pte_alloc() if the page table is pinned already
and if this is the case, don't do the pinning. This is a rather clean
solution, but will result in other failures if a page table is used
multiple times (this case would be caught today as in the failure
above).
My tendency is towards solution 3 as it is local to Xen code and has the
best performance.
Any thoughts?
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xen-unstable linux-5.14: 1 of 2 multicall(s) failed: cpu 0
2021-09-07 7:58 ` Juergen Gross
@ 2021-09-07 8:11 ` Jan Beulich
2021-09-07 8:15 ` Juergen Gross
0 siblings, 1 reply; 8+ messages in thread
From: Jan Beulich @ 2021-09-07 8:11 UTC (permalink / raw)
To: Juergen Gross; +Cc: xen-devel, Sander Eikelenboom
On 07.09.2021 09:58, Juergen Gross wrote:
> On 06.09.21 23:35, Sander Eikelenboom wrote:
>> L.S.,
>>
>> On my AMD box running:
>> xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
>> linux kernel: 5.14.1
>>
>> With this setup I'm encountering some issues in dom0, see below.
>>
>> --
>> Sander
>>
>> xl dmesg gives:
>>
>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 63b936 already pinned
>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a0622 already pinned
>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6b63da already pinned
>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 638dd9 already pinned
>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 68a7bc already pinned
>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 63c27d already pinned
>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a04f2 already pinned
>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 690d49 already pinned
>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6959a0 already pinned
>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a055e already pinned
>> (XEN) [2021-09-06 18:15:04.090] mm.c:3506:d0v0 mfn 639437 already pinned
>>
>>
>> dmesg gives:
>>
>> [34321.304270] ------------[ cut here ]------------
>> [34321.304277] WARNING: CPU: 0 PID: 23628 at
>> arch/x86/xen/multicalls.c:102 xen_mc_flush+0x176/0x1a0
>> [34321.304288] Modules linked in:
>> [34321.304291] CPU: 0 PID: 23628 Comm: apt-get Not tainted
>> 5.14.1-20210906-doflr-mac80211debug+ #1
>> [34321.304294] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
>> V1.8B1 09/13/2010
>> [34321.304296] RIP: e030:xen_mc_flush+0x176/0x1a0
>> [34321.304300] Code: 89 45 18 48 c1 e9 3f 48 89 ce e9 20 ff ff ff e8 60
>> 03 00 00 66 90 5b 5d 41 5c 41 5d c3 48 c7 45 18 ea ff ff ff be 01 00 00
>> 00 <0f> 0b 8b 55 00 48 c7 c7 10 97 aa 82 31 db 49 c7 c5 38 97 aa 82 65
>> [34321.304303] RSP: e02b:ffffc90000a97c90 EFLAGS: 00010002
>> [34321.304305] RAX: ffff88807d416398 RBX: ffff88807d416350 RCX:
>> ffff88807d416398
>> [34321.304306] RDX: 0000000000000001 RSI: 0000000000000001 RDI:
>> deadbeefdeadf00d
>> [34321.304308] RBP: ffff88807d416300 R08: aaaaaaaaaaaaaaaa R09:
>> ffff888006160cc0
>> [34321.304309] R10: deadbeefdeadf00d R11: ffffea000026a600 R12:
>> 0000000000000000
>> [34321.304310] R13: ffff888012f6b000 R14: 0000000012f6b000 R15:
>> 0000000000000001
>> [34321.304320] FS: 00007f5071177800(0000) GS:ffff88807d400000(0000)
>> knlGS:0000000000000000
>> [34321.304322] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [34321.304323] CR2: 00007f506f542000 CR3: 00000000160cc000 CR4:
>> 0000000000000660
>> [34321.304326] Call Trace:
>> [34321.304331] xen_alloc_pte+0x294/0x320
>> [34321.304334] move_pgt_entry+0x165/0x4b0
>> [34321.304339] move_page_tables+0x6fa/0x8d0
>> [34321.304342] move_vma.isra.44+0x138/0x500
>> [34321.304345] __x64_sys_mremap+0x296/0x410
>> [34321.304348] do_syscall_64+0x3a/0x80
>> [34321.304352] entry_SYSCALL_64_after_hwframe+0x44/0xae
>> [34321.304355] RIP: 0033:0x7f507196301a
>
> I can see why this failure is occurring, but I'm not sure which way is
> the best to fix it.
>
> The problem is that a pinned page table is moved: the pmd entry
> referencing it is cleared and a new reference is put into the pmd.
> This is done by getting the old pmd entry, clearing that entry, and then
> using pmd_populate() to write the new pmd entry. pmd_populate() will
> lead to a call of xen_pte_alloc() trying to pin the referenced page
> table, which is failing, as it is already pinned.
>
> The problem has been introduced by commit 0881ace292b662d2 in kernel
> 5.14.
>
> Following solutions would be possible:
>
> 1. When running as PV guest skip the optimization of move_pgt_entry()
> by letting arch_supports_page_table_move() return false. This will
> result in a performance drop in some cases.
>
> 2. Unpin the page table before calling pmd_populate(). This adds some
> unneeded hypercall and without flushing the TLB I'm feeling uneasy
> to do that.
I agree as far as the "unneeded hypercall" aspect goes, but I don't
see any connection to the TLB (or a need to flush it): Pinning has
nothing to do with insertion into a live page table; a pinned page
table can be entirely free floating. It's the removal from a
(possibly) live page table which would require a flush.
> 3. Add a check in xen_pte_alloc() if the page table is pinned already
> and if this is the case, don't do the pinning. This is a rather clean
> solution, but will result in other failures if a page table is used
> multiple times (this case would be caught today as in the failure
> above).
>
> My tendency is towards solution 3 as it is local to Xen code and has the
> best performance.
I agree 3 looks most promising. I can't judge how big of a risk
there is for a page table to get used in more than one place, and
hence how important it is to be able to detect that case.
Jan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xen-unstable linux-5.14: 1 of 2 multicall(s) failed: cpu 0
2021-09-07 8:11 ` Jan Beulich
@ 2021-09-07 8:15 ` Juergen Gross
0 siblings, 0 replies; 8+ messages in thread
From: Juergen Gross @ 2021-09-07 8:15 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Sander Eikelenboom
[-- Attachment #1.1.1: Type: text/plain, Size: 5587 bytes --]
On 07.09.21 10:11, Jan Beulich wrote:
> On 07.09.2021 09:58, Juergen Gross wrote:
>> On 06.09.21 23:35, Sander Eikelenboom wrote:
>>> L.S.,
>>>
>>> On my AMD box running:
>>> xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
>>> linux kernel: 5.14.1
>>>
>>> With this setup I'm encountering some issues in dom0, see below.
>>>
>>> --
>>> Sander
>>>
>>> xl dmesg gives:
>>>
>>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 63b936 already pinned
>>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a0622 already pinned
>>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6b63da already pinned
>>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 638dd9 already pinned
>>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 68a7bc already pinned
>>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 63c27d already pinned
>>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a04f2 already pinned
>>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 690d49 already pinned
>>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6959a0 already pinned
>>> (XEN) [2021-09-06 18:15:04.089] mm.c:3506:d0v0 mfn 6a055e already pinned
>>> (XEN) [2021-09-06 18:15:04.090] mm.c:3506:d0v0 mfn 639437 already pinned
>>>
>>>
>>> dmesg gives:
>>>
>>> [34321.304270] ------------[ cut here ]------------
>>> [34321.304277] WARNING: CPU: 0 PID: 23628 at
>>> arch/x86/xen/multicalls.c:102 xen_mc_flush+0x176/0x1a0
>>> [34321.304288] Modules linked in:
>>> [34321.304291] CPU: 0 PID: 23628 Comm: apt-get Not tainted
>>> 5.14.1-20210906-doflr-mac80211debug+ #1
>>> [34321.304294] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
>>> V1.8B1 09/13/2010
>>> [34321.304296] RIP: e030:xen_mc_flush+0x176/0x1a0
>>> [34321.304300] Code: 89 45 18 48 c1 e9 3f 48 89 ce e9 20 ff ff ff e8 60
>>> 03 00 00 66 90 5b 5d 41 5c 41 5d c3 48 c7 45 18 ea ff ff ff be 01 00 00
>>> 00 <0f> 0b 8b 55 00 48 c7 c7 10 97 aa 82 31 db 49 c7 c5 38 97 aa 82 65
>>> [34321.304303] RSP: e02b:ffffc90000a97c90 EFLAGS: 00010002
>>> [34321.304305] RAX: ffff88807d416398 RBX: ffff88807d416350 RCX:
>>> ffff88807d416398
>>> [34321.304306] RDX: 0000000000000001 RSI: 0000000000000001 RDI:
>>> deadbeefdeadf00d
>>> [34321.304308] RBP: ffff88807d416300 R08: aaaaaaaaaaaaaaaa R09:
>>> ffff888006160cc0
>>> [34321.304309] R10: deadbeefdeadf00d R11: ffffea000026a600 R12:
>>> 0000000000000000
>>> [34321.304310] R13: ffff888012f6b000 R14: 0000000012f6b000 R15:
>>> 0000000000000001
>>> [34321.304320] FS: 00007f5071177800(0000) GS:ffff88807d400000(0000)
>>> knlGS:0000000000000000
>>> [34321.304322] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [34321.304323] CR2: 00007f506f542000 CR3: 00000000160cc000 CR4:
>>> 0000000000000660
>>> [34321.304326] Call Trace:
>>> [34321.304331] xen_alloc_pte+0x294/0x320
>>> [34321.304334] move_pgt_entry+0x165/0x4b0
>>> [34321.304339] move_page_tables+0x6fa/0x8d0
>>> [34321.304342] move_vma.isra.44+0x138/0x500
>>> [34321.304345] __x64_sys_mremap+0x296/0x410
>>> [34321.304348] do_syscall_64+0x3a/0x80
>>> [34321.304352] entry_SYSCALL_64_after_hwframe+0x44/0xae
>>> [34321.304355] RIP: 0033:0x7f507196301a
>>
>> I can see why this failure is occurring, but I'm not sure which way is
>> the best to fix it.
>>
>> The problem is that a pinned page table is moved: the pmd entry
>> referencing it is cleared and a new reference is put into the pmd.
>> This is done by getting the old pmd entry, clearing that entry, and then
>> using pmd_populate() to write the new pmd entry. pmd_populate() will
>> lead to a call of xen_pte_alloc() trying to pin the referenced page
>> table, which is failing, as it is already pinned.
>>
>> The problem has been introduced by commit 0881ace292b662d2 in kernel
>> 5.14.
>>
>> Following solutions would be possible:
>>
>> 1. When running as PV guest skip the optimization of move_pgt_entry()
>> by letting arch_supports_page_table_move() return false. This will
>> result in a performance drop in some cases.
>>
>> 2. Unpin the page table before calling pmd_populate(). This adds some
>> unneeded hypercall and without flushing the TLB I'm feeling uneasy
>> to do that.
>
> I agree as far as the "unneeded hypercall" aspect goes, but I don't
> see any connection to the TLB (or a need to flush it): Pinning has
> nothing to do with insertion into a live page table; a pinned page
> table can be entirely free floating. It's the removal from a
> (possibly) live page table which would require a flush.
And this removal is happening:
/* Clear the pmd */
pmd = *old_pmd;
pmd_clear(old_pmd);
VM_BUG_ON(!pmd_none(*new_pmd));
pmd_populate(mm, new_pmd, pmd_pgtable(pmd));
So unpinning after calling pmd_clear() seems to be risky.
>
>> 3. Add a check in xen_pte_alloc() if the page table is pinned already
>> and if this is the case, don't do the pinning. This is a rather clean
>> solution, but will result in other failures if a page table is used
>> multiple times (this case would be caught today as in the failure
>> above).
>>
>> My tendency is towards solution 3 as it is local to Xen code and has the
>> best performance.
>
> I agree 3 looks most promising. I can't judge how big of a risk
> there is for a page table to get used in more than one place, and
> hence how important it is to be able to detect that case.
Thanks. I'm going that route then.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xen-unstable linux-5.14: 1 of 2 multicall(s) failed: cpu 0
2021-09-06 21:35 xen-unstable linux-5.14: 1 of 2 multicall(s) failed: cpu 0 Sander Eikelenboom
2021-09-07 6:54 ` Jan Beulich
2021-09-07 7:58 ` Juergen Gross
@ 2021-09-07 13:53 ` Juergen Gross
2021-09-07 19:52 ` Sander Eikelenboom
2 siblings, 1 reply; 8+ messages in thread
From: Juergen Gross @ 2021-09-07 13:53 UTC (permalink / raw)
To: Sander Eikelenboom, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 375 bytes --]
On 06.09.21 23:35, Sander Eikelenboom wrote:
> L.S.,
>
> On my AMD box running:
> xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
> linux kernel: 5.14.1
>
> With this setup I'm encountering some issues in dom0, see below.
Could you test whether the attached patch (only compile tested)
fixes the issue for you?
Juergen
[-- Attachment #1.1.2: 0001-xen-fix-usage-of-pmd-pud_poplulate-in-mremap-for-pv-.patch --]
[-- Type: text/x-patch, Size: 4837 bytes --]
From c9e4ce85bcb9003ffa4877743e1792ac6ec24f19 Mon Sep 17 00:00:00 2001
From: Juergen Gross <jgross@suse.com>
To: x86@kernel.org
To: linux-kernel@vger.kernel.org
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: xen-devel@lists.xenproject.org
Date: Tue, 7 Sep 2021 15:17:39 +0200
Subject: [PATCH] xen: fix usage of pmd/pud_poplulate in mremap for pv guests
Commit 0881ace292b662 ("mm/mremap: use pmd/pud_poplulate to update page
table entries") introduced a regression when running as Xen PV guest.
Today pmd/pud_poplulate() for Xen PV assumes that the PFN inserted is
referencing a not yet used page table. In case of move_normal_pmd/pud()
this is not true, resulting in WARN splats like:
[34321.304270] ------------[ cut here ]------------
[34321.304277] WARNING: CPU: 0 PID: 23628 at arch/x86/xen/multicalls.c:102 xen_mc_flush+0x176/0x1a0
[34321.304288] Modules linked in:
[34321.304291] CPU: 0 PID: 23628 Comm: apt-get Not tainted 5.14.1-20210906-doflr-mac80211debug+ #1
[34321.304294] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010
[34321.304296] RIP: e030:xen_mc_flush+0x176/0x1a0
[34321.304300] Code: 89 45 18 48 c1 e9 3f 48 89 ce e9 20 ff ff ff e8 60 03 00 00 66 90 5b 5d 41 5c 41 5d c3 48 c7 45 18 ea ff ff ff be 01 00 00 00 <0f> 0b 8b 55 00 48 c7 c7 10 97 aa 82 31 db 49 c7 c5 38 97 aa 82 65
[34321.304303] RSP: e02b:ffffc90000a97c90 EFLAGS: 00010002
[34321.304305] RAX: ffff88807d416398 RBX: ffff88807d416350 RCX: ffff88807d416398
[34321.304306] RDX: 0000000000000001 RSI: 0000000000000001 RDI: deadbeefdeadf00d
[34321.304308] RBP: ffff88807d416300 R08: aaaaaaaaaaaaaaaa R09: ffff888006160cc0
[34321.304309] R10: deadbeefdeadf00d R11: ffffea000026a600 R12: 0000000000000000
[34321.304310] R13: ffff888012f6b000 R14: 0000000012f6b000 R15: 0000000000000001
[34321.304320] FS: 00007f5071177800(0000) GS:ffff88807d400000(0000) knlGS:0000000000000000
[34321.304322] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[34321.304323] CR2: 00007f506f542000 CR3: 00000000160cc000 CR4: 0000000000000660
[34321.304326] Call Trace:
[34321.304331] xen_alloc_pte+0x294/0x320
[34321.304334] move_pgt_entry+0x165/0x4b0
[34321.304339] move_page_tables+0x6fa/0x8d0
[34321.304342] move_vma.isra.44+0x138/0x500
[34321.304345] __x64_sys_mremap+0x296/0x410
[34321.304348] do_syscall_64+0x3a/0x80
[34321.304352] entry_SYSCALL_64_after_hwframe+0x44/0xae
[34321.304355] RIP: 0033:0x7f507196301a
[34321.304358] Code: 73 01 c3 48 8b 0d 76 0e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 19 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 46 0e 0c 00 f7 d8 64 89 01 48
[34321.304360] RSP: 002b:00007ffda1eecd38 EFLAGS: 00000246 ORIG_RAX: 0000000000000019
[34321.304362] RAX: ffffffffffffffda RBX: 000056205f950f30 RCX: 00007f507196301a
[34321.304363] RDX: 0000000001a00000 RSI: 0000000001900000 RDI: 00007f506dc56000
[34321.304364] RBP: 0000000001a00000 R08: 0000000000000010 R09: 0000000000000004
[34321.304365] R10: 0000000000000001 R11: 0000000000000246 R12: 00007f506dc56060
[34321.304367] R13: 00007f506dc56000 R14: 00007f506dc56060 R15: 000056205f950f30
[34321.304368] ---[ end trace a19885b78fe8f33e ]---
[34321.304370] 1 of 2 multicall(s) failed: cpu 0
[34321.304371] call 2: op=12297829382473034410 arg=[aaaaaaaaaaaaaaaa] result=-22
Fix that by modifying xen_alloc_ptpage() to only pin the page table in
case it wasn't pinned already.
Fixes: 0881ace292b662 ("mm/mremap: use pmd/pud_poplulate to update page table entries")
Cc: <stable@vger.kernel.org>
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
arch/x86/xen/mmu_pv.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 1df5f01529e5..8d751939c6f3 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -1518,14 +1518,17 @@ static inline void xen_alloc_ptpage(struct mm_struct *mm, unsigned long pfn,
if (pinned) {
struct page *page = pfn_to_page(pfn);
- if (static_branch_likely(&xen_struct_pages_ready))
+ pinned = false;
+ if (static_branch_likely(&xen_struct_pages_ready)) {
+ pinned = PagePinned(page);
SetPagePinned(page);
+ }
xen_mc_batch();
__set_pfn_prot(pfn, PAGE_KERNEL_RO);
- if (level == PT_PTE && USE_SPLIT_PTE_PTLOCKS)
+ if (level == PT_PTE && USE_SPLIT_PTE_PTLOCKS && !pinned)
__pin_pagetable_pfn(MMUEXT_PIN_L1_TABLE, pfn);
xen_mc_issue(PARAVIRT_LAZY_MMU);
--
2.26.2
[-- Attachment #1.1.3: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: xen-unstable linux-5.14: 1 of 2 multicall(s) failed: cpu 0
2021-09-07 13:53 ` Juergen Gross
@ 2021-09-07 19:52 ` Sander Eikelenboom
2021-09-08 7:15 ` Sander Eikelenboom
0 siblings, 1 reply; 8+ messages in thread
From: Sander Eikelenboom @ 2021-09-07 19:52 UTC (permalink / raw)
To: Juergen Gross, xen-devel
On 07/09/2021 15:53, Juergen Gross wrote:
> On 06.09.21 23:35, Sander Eikelenboom wrote:
>> L.S.,
>>
>> On my AMD box running:
>> xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
>> linux kernel: 5.14.1
>>
>> With this setup I'm encountering some issues in dom0, see below.
>
> Could you test whether the attached patch (only compile tested)
> fixes the issue for you?
>
>
> Juergen
>
Sure, running it now.
Since I haven't got a clear trigger, will report tomorrow if the logs stay clean :)
Thanks so far !
--
Sander
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xen-unstable linux-5.14: 1 of 2 multicall(s) failed: cpu 0
2021-09-07 19:52 ` Sander Eikelenboom
@ 2021-09-08 7:15 ` Sander Eikelenboom
0 siblings, 0 replies; 8+ messages in thread
From: Sander Eikelenboom @ 2021-09-08 7:15 UTC (permalink / raw)
To: Juergen Gross, xen-devel
On 07/09/2021 21:52, Sander Eikelenboom wrote:
> On 07/09/2021 15:53, Juergen Gross wrote:
>> On 06.09.21 23:35, Sander Eikelenboom wrote:
>>> L.S.,
>>>
>>> On my AMD box running:
>>> xen-unstable changeset: Fri Sep 3 15:10:43 2021 +0200 git:2d4978ead4
>>> linux kernel: 5.14.1
>>>
>>> With this setup I'm encountering some issues in dom0, see below.
>>
>> Could you test whether the attached patch (only compile tested)
>> fixes the issue for you?
>>
>>
>> Juergen
>>
>
> Sure, running it now.
> Since I haven't got a clear trigger, will report tomorrow if the logs stay clean :)
>
> Thanks so far !
>
> --
> Sander
>
>
Hi Juergen,
So far so good, it survived the night without issues.
So I think you can add a Tested-By.
Thanks for the swift fix !
--
Sander
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-09-08 7:15 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-06 21:35 xen-unstable linux-5.14: 1 of 2 multicall(s) failed: cpu 0 Sander Eikelenboom
2021-09-07 6:54 ` Jan Beulich
2021-09-07 7:58 ` Juergen Gross
2021-09-07 8:11 ` Jan Beulich
2021-09-07 8:15 ` Juergen Gross
2021-09-07 13:53 ` Juergen Gross
2021-09-07 19:52 ` Sander Eikelenboom
2021-09-08 7:15 ` Sander Eikelenboom
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).