* Regression in guest destruction caused by altp2m
@ 2015-07-27 15:18 Wei Liu
2015-07-27 18:09 ` Wei Liu
0 siblings, 1 reply; 6+ messages in thread
From: Wei Liu @ 2015-07-27 15:18 UTC (permalink / raw)
To: xen-devel, ravi.sahita, edmund.h.white
Cc: George Dunlap, Andrew Cooper, wei.liu2, Jan Beulich, tim
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)
Wei.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Regression in guest destruction caused by altp2m
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
0 siblings, 1 reply; 6+ messages in thread
From: Wei Liu @ 2015-07-27 18:09 UTC (permalink / raw)
To: xen-devel, ravi.sahita, edmund.h.white
Cc: George Dunlap, Andrew Cooper, wei.liu2, Jan Beulich, tim
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.
Wei.
>
> Wei.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Regression in guest destruction caused by altp2m
2015-07-27 18:09 ` Wei Liu
@ 2015-07-27 23:21 ` Andrew Cooper
2015-07-27 23:26 ` Sahita, Ravi
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cooper @ 2015-07-27 23:21 UTC (permalink / raw)
To: Wei Liu, xen-devel, ravi.sahita, edmund.h.white
Cc: George Dunlap, tim, Jan Beulich
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Regression in guest destruction caused by altp2m
2015-07-27 23:21 ` Andrew Cooper
@ 2015-07-27 23:26 ` Sahita, Ravi
2015-07-29 10:03 ` Wei Liu
0 siblings, 1 reply; 6+ messages in thread
From: Sahita, Ravi @ 2015-07-27 23:26 UTC (permalink / raw)
To: Andrew Cooper, Wei Liu, xen-devel
Cc: George Dunlap, Sahita, Ravi, tim, White, Edmund H, Jan Beulich
>From: Andrew Cooper [mailto:amc96@hermes.cam.ac.uk] On Behalf Of
>Andrew Cooper
>Sent: Monday, July 27, 2015 4:22 PM
>
>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.
Yes -
the check for hvm_altp2m_supported() before altp2m_vcpu_destroy() was missing - will send a patch tonight.
Ravi
>
>~Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Regression in guest destruction caused by altp2m
2015-07-27 23:26 ` Sahita, Ravi
@ 2015-07-29 10:03 ` Wei Liu
2015-07-29 16:41 ` Sahita, Ravi
0 siblings, 1 reply; 6+ messages in thread
From: Wei Liu @ 2015-07-29 10:03 UTC (permalink / raw)
To: Sahita, Ravi
Cc: Wei Liu, George Dunlap, Andrew Cooper, tim, White, Edmund H,
Jan Beulich, xen-devel
On Mon, Jul 27, 2015 at 11:26:36PM +0000, Sahita, Ravi wrote:
[...]
> >> 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.
>
> Yes -
> the check for hvm_altp2m_supported() before altp2m_vcpu_destroy() was missing - will send a patch tonight.
>
Hi Ravi
Any update on this? This is a blocker for the release. Please fix it as
soon as possible.
Wei.
> Ravi
>
>
> >
> >~Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Regression in guest destruction caused by altp2m
2015-07-29 10:03 ` Wei Liu
@ 2015-07-29 16:41 ` Sahita, Ravi
0 siblings, 0 replies; 6+ messages in thread
From: Sahita, Ravi @ 2015-07-29 16:41 UTC (permalink / raw)
To: Wei Liu
Cc: George Dunlap, Andrew Cooper, tim, White, Edmund H, Jan Beulich,
xen-devel
>From: Wei Liu [mailto:wei.liu2@citrix.com]
>Sent: Wednesday, July 29, 2015 3:04 AM
>
>On Mon, Jul 27, 2015 at 11:26:36PM +0000, Sahita, Ravi wrote:
>[...]
>> >> 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.
>>
>> Yes -
>> the check for hvm_altp2m_supported() before altp2m_vcpu_destroy() was
>missing - will send a patch tonight.
>>
>
>Hi Ravi
>
>Any update on this? This is a blocker for the release. Please fix it as
>soon as possible.
>
Just posted it - Ravi
>Wei.
>
>> Ravi
>>
>>
>> >
>> >~Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-07-29 16:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2015-07-27 23:26 ` Sahita, Ravi
2015-07-29 10:03 ` Wei Liu
2015-07-29 16:41 ` Sahita, Ravi
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).