From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>,
xen-devel@lists.xenproject.org, ravi.sahita@intel.com,
edmund.h.white@intel.com
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
tim@xen.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: Regression in guest destruction caused by altp2m
Date: Tue, 28 Jul 2015 00:21:48 +0100 [thread overview]
Message-ID: <55B6BD0C.7030107@citrix.com> (raw)
In-Reply-To: <20150727180939.GC5111@zion.uk.xensource.com>
On 27/07/2015 19:09, Wei Liu wrote:
> On Mon, Jul 27, 2015 at 04:18:15PM +0100, Wei Liu wrote:
>> Found this when I did "xl destroy" to a hvm guest *without* altp2m turned
>> on.
>>
>> Current staging branch.
>>
>> (XEN) ----[ Xen-4.6-unstable x86_64 debug=y Tainted: C ]----
>> (XEN) CPU: 0
>> (XEN) RIP: e008:[<ffff82d0801fce0d>] vmx_vmenter_helper+0x263/0x2f3
>> (XEN) RFLAGS: 0000000000010242 CONTEXT: hypervisor (d0v0)
>> (XEN) rax: 000000000000201a rbx: ffff8300cf5f9000 rcx: 0000000000000000
>> (XEN) rdx: 0000000000000200 rsi: ffff830225fc5000 rdi: ffff8300cf5f9000
>> (XEN) rbp: ffff8300cf30fde8 rsp: ffff8300cf30fdd8 r8: ffff8300cf0fc5e0
>> (XEN) r9: 00000016e7ea5ca3 r10: 0000000000000000 r11: 00000016f1000b66
>> (XEN) r12: ffff830227b18740 r13: ffff830227bda250 r14: ffff830227bda240
>> (XEN) r15: 0000000000000000 cr0: 0000000080050033 cr4: 00000000000026e0
>> (XEN) cr3: 000000000f03a000 cr2: 00007fb13dc65150
>> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
>> (XEN) Xen stack trace from rsp=ffff8300cf30fdd8:
>> (XEN) ffff8300cf5f9000 ffff8300cf5f9000 ffff8300cf30fdf8 ffff82d0801d95fb
>> (XEN) ffff8300cf30fe18 ffff82d0802145eb ffff82d08012d455 ffff830227bda250
>> (XEN) ffff8300cf30fe48 ffff82d0801d3e0c ffff8300cf5f9000 0000000000000001
>> (XEN) ffff830227bdaf28 ffff830227bda000 ffff8300cf30fe68 ffff82d080174c6f
>> (XEN) ffff8300cf5f9000 ffff8300cf5f9000 ffff8300cf30fe98 ffff82d080105e07
>> (XEN) ffff82d0803545c0 0000000000000000 0000000000000000 ffff8300cf308000
>> (XEN) ffff8300cf30fec8 ffff82d08012148a ffff82d080328080 ffff82d080328080
>> (XEN) ffff82d080328080 ffffffffffffffff ffff8300cf30fef8 ffff82d08012cbe7
>> (XEN) ffff8300ce68e000 00007fb13dc65150 ffffea00000715a0 0000000000000000
>> (XEN) ffff8300cf30ff08 ffff82d08012cc3f 00007cff30cf00c7 ffff82d08024dd51
>> (XEN) 0000000000000000 0000000000000000 ffffea00000715a0 00007fb13dc65150
>> (XEN) ffff8800cd4ff3d8 ffffea0000267a50 ffff880000000328 00000000000000a9
>> (XEN) ffffea00000715a0 ffff8800cd4ff3d8 ffff880207c997b9 0000000000267a50
>> (XEN) 00007fb13dc65150 ffff8800cd4ff3d8 ffffea0000267a50 000000fa00000000
>> (XEN) ffffffff8113d09d 000000000000e033 0000000000000202 ffff88000b807d68
>> (XEN) 000000000000e02b 000000000000beef 000000000000beef 000000000000beef
>> (XEN) 000000000000beef 0000000000000000 ffff8300ce68e000 0000000000000000
>> (XEN) 0000000000000000
>> (XEN) Xen call trace:
>> (XEN) [<ffff82d0801fce0d>] vmx_vmenter_helper+0x263/0x2f3
>> (XEN) [<ffff82d0801d95fb>] altp2m_vcpu_update_p2m+0x12/0x15
>> (XEN) [<ffff82d0802145eb>] altp2m_vcpu_destroy+0x6b/0x94
>> (XEN) [<ffff82d0801d3e0c>] hvm_vcpu_destroy+0x5a/0xa7
>> (XEN) [<ffff82d080174c6f>] vcpu_destroy+0x5d/0x72
>> (XEN) [<ffff82d080105e07>] complete_domain_destroy+0x49/0x186
>> (XEN) [<ffff82d08012148a>] rcu_process_callbacks+0x144/0x1a5
>> (XEN) [<ffff82d08012cbe7>] __do_softirq+0x82/0x8d
>> (XEN) [<ffff82d08012cc3f>] do_softirq+0x13/0x15
>> (XEN) [<ffff82d08024dd51>] process_softirqs+0x21/0x30
>> (XEN)
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) FATAL TRAP: vector = 6 (invalid opcode)
>> (XEN) ****************************************
>> (XEN)
> This makes me think it doesn't matter if I do "xl destroy" or just
> normal shutdown. And another test to normally shutdown guest confirmed
> that.
>
> The machine I have is quite old and doesn't support EPT. The real issues
> seems to be that you failed to properly disable that feature for old
> machines.
The altp2m feature is designed (and implemented) to be emulated on
systems lacking hardware capabilities.
As such, teardown is necessary even on older systems, but I would agree
that there appears to be a bug.
~Andrew
next prev parent reply other threads:[~2015-07-27 23:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 15:18 Regression in guest destruction caused by altp2m Wei Liu
2015-07-27 18:09 ` Wei Liu
2015-07-27 23:21 ` Andrew Cooper [this message]
2015-07-27 23:26 ` Sahita, Ravi
2015-07-29 10:03 ` Wei Liu
2015-07-29 16:41 ` Sahita, Ravi
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=55B6BD0C.7030107@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=edmund.h.white@intel.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ravi.sahita@intel.com \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.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.