From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
Cc: tim@xen.org, jbeulich@suse.com
Subject: Re: [PATCH v9 0/9] xen/x86: various XPTI speedups
Date: Tue, 1 May 2018 10:28:41 +0100 [thread overview]
Message-ID: <f9f4321e-3911-81fe-f2b9-d65fcb0f1926@citrix.com> (raw)
In-Reply-To: <20180426113318.21838-1-jgross@suse.com>
On 26/04/18 12:33, Juergen Gross wrote:
> This patch series aims at reducing the overhead of the XPTI Meltdown
> mitigation.
With just the first 3 patches of this series (in a bisection attempt),
on a XenServer build based off staging, XenRT finds the following:
(XEN) Assertion 'first_dirty != INVALID_DIRTY_IDX || !(pg[i].count_info & PGC_need_scrub)' failed at page_alloc.c:979
(XEN) ----[ Xen-4.11.0-6.0.0-d x86_64 debug=y Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82d080229914>] page_alloc.c#alloc_heap_pages+0x371/0x6f2
(XEN) RFLAGS: 0000000000010286 CONTEXT: hypervisor (d33v0)
(XEN) rax: ffff82e01307ade8 rbx: 000000000007ffff rcx: 8180000000000000
(XEN) rdx: 0000000000000000 rsi: 00000000000001b5 rdi: 0000000000000000
(XEN) rbp: ffff8300952b7ba8 rsp: ffff8300952b7b18 r8: 8000000000000000
(XEN) r9: ffff82e01307ade8 r10: 0180000000000000 r11: 7fffffffffffffff
(XEN) r12: 0000000000000000 r13: 00000000024c2e83 r14: 0000000000000000
(XEN) r15: ffff82e01307add8 cr0: 0000000080050033 cr4: 00000000001526e0
(XEN) cr3: 0000000799c41000 cr2: 00007fdaf5539000
(XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Xen code around <ffff82d080229914> (page_alloc.c#alloc_heap_pages+0x371/0x6f2):
(XEN) ff 0f 0b 48 85 c9 79 31 <0f> 0b 48 c7 42 08 00 00 00 00 c7 42 10 00 00 00
(XEN) Xen stack trace from rsp=ffff8300952b7b18:
(XEN) 0000000000000001 ffff830799cdd000 0000000000000000 00000000003037e9
(XEN) 0000000100000004 ffff8300952b7b68 0000000100000000 ffff830095738000
(XEN) ffff8300952b7be8 000000008033bfe8 ffff82e01295e540 0000000000001adc
(XEN) ffff830756971770 0000000000000028 0000000000000000 ffff830799cdd000
(XEN) 0000000000000000 ffff830799cdd000 ffff8300952b7be8 ffff82d080229d4c
(XEN) 0000000000000000 ffff8300952b7d40 0000000000000000 0000000000000000
(XEN) 00000000000000a8 ffff830799cdd000 ffff8300952b7c98 ffff82d080221d90
(XEN) 0000000100000000 ffff830799cdd000 0000000000000000 0000000099cdd000
(XEN) ffff82e009cd0fd8 00000000000e7b1f ffff8300952b7c88 0000000000000020
(XEN) ffff8800e7b1fdd8 0000000000000002 0000000000000006 ffff830799cdd000
(XEN) ffff8300952b7c78 000000000039f480 0000000000000000 000000000000008d
(XEN) ffff8800e7b1fdd8 ffff830799cdd000 0000000000000006 ffff830799cdd000
(XEN) ffff8300952b7db8 ffff82d080223ad7 0000000000000046 ffff830088ff9000
(XEN) ffff8300952b7d18 ffff82d08023cfaf ffff82c000230118 ffff830842ceeb8c
(XEN) ffff82e009f54db8 00000000003bc78b ffff830842cd2770 ffff830088ff9000
(XEN) 0000000000000000 0000000000000000 ffff83085d6b9350 0000000000000000
(XEN) ffff8300952b7d28 ffff82d08023d766 ffff8300952b7d58 ffff82d08020c9a2
(XEN) ffff830842cee000 ffff830799cdd000 ffffffff81adbec0 0000000000000200
(XEN) 0000008d00000000 ffff82d000000000 ffffffff81adbec0 0000000000000200
(XEN) 0000000000000000 0000000000007ff0 ffff83085d6b9350 0000000000000006
(XEN) Xen call trace:
(XEN) [<ffff82d080229914>] page_alloc.c#alloc_heap_pages+0x371/0x6f2
(XEN) [<ffff82d080229d4c>] alloc_domheap_pages+0xb7/0x157
(XEN) [<ffff82d080221d90>] memory.c#populate_physmap+0x27e/0x4c9
(XEN) [<ffff82d080223ad7>] do_memory_op+0x2e2/0x2695
(XEN) [<ffff82d080308be9>] hypercall.c#hvm_memory_op+0x36/0x60
(XEN) [<ffff82d0803091c2>] hvm_hypercall+0x5af/0x681
(XEN) [<ffff82d08032fee6>] vmx_vmexit_handler+0x1040/0x1e14
(XEN) [<ffff82d080335f88>] vmx_asm_vmexit_handler+0xe8/0x250
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Assertion 'first_dirty != INVALID_DIRTY_IDX || !(pg[i].count_info & PGC_need_scrub)' failed at page_alloc.c:979
(XEN) ****************************************
Running repeated tests on adjacent builds, we never see the assertion
failure without the patches (6 runs), and have so far seen for 3 of 4
runs (2 still pending) with the patches.
What is rather strange is that there is a lot of migration and
ballooning going on, but only for HVM (Debian Jessie, not that this
should matter) VMs. dom0 will be the only PV domain in the system, and
is 64bit.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-05-01 9:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-26 11:33 [PATCH v9 0/9] xen/x86: various XPTI speedups Juergen Gross
2018-04-26 11:33 ` [PATCH v9 1/9] x86/xpti: avoid copying L4 page table contents when possible Juergen Gross
2018-04-26 14:01 ` Tim Deegan
2018-04-26 11:33 ` [PATCH v9 2/9] xen/x86: add a function for modifying cr3 Juergen Gross
2018-04-26 11:33 ` [PATCH v9 3/9] xen/x86: support per-domain flag for xpti Juergen Gross
2018-04-27 7:55 ` Sergey Dyasli
2018-04-27 7:59 ` Juergen Gross
2018-04-27 8:15 ` Jan Beulich
2018-05-04 15:06 ` Wei Liu
2018-04-26 11:33 ` [PATCH v9 4/9] xen/x86: use invpcid for flushing the TLB Juergen Gross
2018-04-26 11:33 ` [PATCH v9 5/9] xen/x86: disable global pages for domains with XPTI active Juergen Gross
2018-04-26 11:33 ` [PATCH v9 6/9] xen/x86: use flag byte for decision whether xen_cr3 is valid Juergen Gross
2018-04-26 11:33 ` [PATCH v9 7/9] xen/x86: convert pv_guest_cr4_to_real_cr4() to a function Juergen Gross
2018-04-26 11:33 ` [PATCH v9 8/9] xen/x86: add some cr3 helpers Juergen Gross
2018-04-26 11:33 ` [PATCH v9 9/9] xen/x86: use PCID feature Juergen Gross
2018-05-01 9:28 ` Andrew Cooper [this message]
2018-05-02 10:38 ` [PATCH v9 0/9] xen/x86: various XPTI speedups Juergen Gross
2018-05-03 17:41 ` Andrew Cooper
2018-05-03 18:41 ` Juergen Gross
2018-05-04 14:59 ` Wei Liu
2018-05-16 9:06 ` backporting considerations (Re: [PATCH v9 0/9] xen/x86: various XPTI speedups) Jan Beulich
2018-05-16 13:18 ` George Dunlap
2018-05-16 14:01 ` Jan Beulich
2018-05-16 14:53 ` George Dunlap
2018-05-16 16:01 ` Jan Beulich
2018-05-16 16:42 ` George Dunlap
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=f9f4321e-3911-81fe-f2b9-d65fcb0f1926@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=tim@xen.org \
--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 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).