From: Jan Beulich <jbeulich@suse.com>
To: Elliott Mitchell <ehem+xen@m5p.com>
Cc: xen-devel@lists.xenproject.org
Subject: Re: HVM/PVH Balloon crash
Date: Wed, 29 Sep 2021 15:32:15 +0200 [thread overview]
Message-ID: <033cc499-34de-d27a-7b1b-2a0a7ce38672@suse.com> (raw)
In-Reply-To: <YVD59QVbmdVwzYQI@mattapan.m5p.com>
On 27.09.2021 00:53, Elliott Mitchell wrote:
> Getting everything right to recreate is rather inexact. Having an
> equivalent of `sysctl` to turn on the serial console while running might
> be handy...
>
> Luckily get things together and...
Thanks; finally got around to look at this in at least slightly more
detail.
> (XEN) mm locking order violation: 48 > 16
> (XEN) Xen BUG at mm-locks.h:82
> (XEN) ----[ Xen-4.14.3 x86_64 debug=n Not tainted ]----
> (XEN) CPU: 2
> (XEN) RIP: e008:[<ffff82d0402e8be0>] arch/x86/mm/p2m.c#p2m_flush_table+0x240/0x260
> (XEN) RFLAGS: 0000000000010292 CONTEXT: hypervisor (d1v0)
> (XEN) rax: ffff83080b2f106c rbx: ffff83081da0f2d0 rcx: 0000000000000000
> (XEN) rdx: ffff83080b27ffff rsi: 000000000000000a rdi: ffff82d040469738
> (XEN) rbp: ffff82d040580688 rsp: ffff83080b27f8b0 r8: 0000000000000002
> (XEN) r9: 0000000000008000 r10: ffff82d04058f381 r11: ffff82d040375100
> (XEN) r12: ffff82d040580688 r13: ffff83080b27ffff r14: ffff83081ddf6000
> (XEN) r15: 00000000004f8c00 cr0: 000000008005003b cr4: 00000000000406e0
> (XEN) cr3: 000000081dee6000 cr2: 0000000000000000
> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000
> (XEN) ds: 0000 es: 0000 fs: 0010 gs: 0010 ss: 0000 cs: e008
> (XEN) Xen code around <ffff82d0402e8be0> (arch/x86/mm/p2m.c#p2m_flush_table+0x240/0x260):
> (XEN) e3 0c 00 e8 30 7f f6 ff <0f> 0b 66 0f 1f 44 00 00 42 8b 34 20 48 8d 3d 8d
> (XEN) Xen stack trace from rsp=ffff83080b27f8b0:
> [...]
> (XEN) Xen call trace:
> (XEN) [<ffff82d0402e8be0>] R arch/x86/mm/p2m.c#p2m_flush_table+0x240/0x260
> (XEN) [<ffff82d0402ec51c>] S p2m_flush_nestedp2m+0x1c/0x30
> (XEN) [<ffff82d0402e0528>] S arch/x86/mm/hap/hap.c#hap_write_p2m_entry+0x378/0x490
hap_write_p2m_entry() calling p2m_flush_nestedp2m() suggests that
nestedhvm_enabled() was true for the domain. While we will want to
fix this, nested virt is experimental (even in current staging),
and hence there at least is no security concern.
Can you confirm that by leaving nested off you don't run into this
(or a similar) issue?
Of course you not having done this with a debug build (and frame
pointers in particular) leaves a level of uncertainty, i.e. the
real call chain may have been different from what this call trace
suggests.
Jan
> (XEN) [<ffff82d0402f009a>] S arch/x86/mm/p2m-pt.c#p2m_next_level.constprop.10+0x24a/0x2e0
> (XEN) [<ffff82d0402f1097>] S arch/x86/mm/p2m-pt.c#p2m_pt_set_entry+0x3c7/0x7b0
> (XEN) [<ffff82d0402ea0a6>] S p2m_set_entry+0xa6/0x130
> (XEN) [<ffff82d0402f4ecd>] S arch/x86/mm/p2m-pod.c#p2m_pod_zero_check+0x1cd/0x440
> (XEN) [<ffff82d0402f023f>] S arch/x86/mm/p2m-pt.c#do_recalc+0x10f/0x470
> (XEN) [<ffff82d0402f02ed>] S arch/x86/mm/p2m-pt.c#do_recalc+0x1bd/0x470
> (XEN) [<ffff82d0402f00ed>] S arch/x86/mm/p2m-pt.c#p2m_next_level.constprop.10+0x29d/0x2e0
> (XEN) [<ffff82d0402e03da>] S arch/x86/mm/hap/hap.c#hap_write_p2m_entry+0x22a/0x490
> (XEN) [<ffff82d0402f0fe2>] S arch/x86/mm/p2m-pt.c#p2m_pt_set_entry+0x312/0x7b0
> (XEN) [<ffff82d0402f0c4e>] S arch/x86/mm/p2m-pt.c#p2m_pt_get_entry+0x3fe/0x480
> (XEN) [<ffff82d0402f59aa>] S arch/x86/mm/p2m-pod.c#p2m_pod_zero_check_superpage+0x17a/0x600
> (XEN) [<ffff82d0402f5ba0>] S arch/x86/mm/p2m-pod.c#p2m_pod_zero_check_superpage+0x370/0x600
> (XEN) [<ffff82d0402f7c78>] S p2m_pod_demand_populate+0x6b8/0xa90
> (XEN) [<ffff82d0402f0aa6>] S arch/x86/mm/p2m-pt.c#p2m_pt_get_entry+0x256/0x480
> (XEN) [<ffff82d0402e9a1f>] S __get_gfn_type_access+0x6f/0x130
> (XEN) [<ffff82d0402ab12b>] S hvm_hap_nested_page_fault+0xeb/0x760
> (XEN) [<ffff82d04028c87e>] S svm_asm_do_resume+0x12e/0x164
> (XEN) [<ffff82d04028c87e>] S svm_asm_do_resume+0x12e/0x164
>
> The stack trace goes further, but I suspect the rest would be overkill.
> That seems to readily qualify as "Xen bug".
>
>
next prev parent reply other threads:[~2021-09-29 13:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-05 22:10 HVM/PVH Ballon crash Elliott Mitchell
2021-09-06 7:52 ` Jan Beulich
2021-09-06 20:47 ` HVM/PVH Balloon crash Elliott Mitchell
2021-09-07 8:03 ` Jan Beulich
2021-09-07 15:03 ` Elliott Mitchell
2021-09-07 15:57 ` Jan Beulich
2021-09-07 21:40 ` Elliott Mitchell
2021-09-15 2:40 ` Elliott Mitchell
2021-09-15 6:05 ` Jan Beulich
2021-09-26 22:53 ` Elliott Mitchell
2021-09-29 13:32 ` Jan Beulich [this message]
2021-09-29 15:31 ` Elliott Mitchell
2021-09-30 7:08 ` Jan Beulich
2021-10-02 2:35 ` Elliott Mitchell
2021-10-07 7:20 ` Jan Beulich
2021-09-30 7:43 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=033cc499-34de-d27a-7b1b-2a0a7ce38672@suse.com \
--to=jbeulich@suse.com \
--cc=ehem+xen@m5p.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.