Help: a xen crash of 4.8.2 version/////答复: Is there a faster way to restore Virtual machine status in Xen?

* Help: a xen crash of 4.8.2 version/////答复: Is there a faster way to restore Virtual machine status in Xen?
@ 2018-06-29  4:26 Chenjia (C)
  2018-06-29  5:40 ` Jan Beulich
  0 siblings, 1 reply; 19+ messages in thread
From: Chenjia (C) @ 2018-06-29  4:26 UTC (permalink / raw)
  To: xen-devel; +Cc: wangxu (R), Shentao (Terry), zhaobingjian

[-- Attachment #1.1: Type: text/plain, Size: 6259 bytes --]

Dear xen expert:
       We meet a xen bug in our project(our project job is descript in the last email),  the crash information is this:

(XEN) RFLAGS: 0000000000010003 CONTEXT: hypervisor
(XEN) rax: 000000008005003b rbx: ffff83006215f000 rcx: 0000000000000000
(XEN) rdx: 0000000000006c00 rsi: 0000000000000007 rdi: ffff83006215f000
(XEN) rbp: ffff83006215f000 rsp: ffff8340253dfc28 r8: 0000000000000008
(XEN) r9: ffff8340253dff18 r10: 0000000000000000 r11: 0f0f0f0f0f0f0f0f
(XEN) r12: ffff8300621f3000 r13: 0000000000000017 r14: ffff82d080844b60
(XEN) r15: ffff832027d86000 cr0: 000000008005003b cr4: 00000000003526e0
(XEN) cr3: 00000003d3965000 cr2: 0000000000388000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Xen code around <ffff82d0801f0352> (vmx.c#arch/x86/hvm/vmx/vmx.o.unlikely+0x13a/0x1a8):
(XEN) 0f 0b 0f 0b 0f 0b 0f 0b <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b
(XEN) Xen stack trace from rsp=ffff8340253dfc28:
(XEN) ffff833f4abd8000 ffff82d080161920 0000001700000246 ffff8340253dff18
(XEN) ffff83407d9425d0 ffff82d080122ee2 ffff8340253dfcb8 0000000000000001
(XEN) 0000000000000092 00000000000000fd ffff82d080832980 ffff83101d825aa8
(XEN) ffff82d080844b60 ffff82d080166d52 0000000000004000 0000000000000100
(XEN) ffff82d0801e6d00 ffff82d08018d925 0000000000000000 ffff82d0801706cd
(XEN) 0000000000000000 0000000000000000 00000000f0c0c801 ffff83006215f000
(XEN) 0000000000000000 8000000080844b60 0000000000000246 ffff82d08085a740
(XEN) 0000000000000206 ffff82d08012b627 000000000000c000 ffff82d080402180
(XEN) ffff82d0801e6d00 0000000000000001 ffff8300621a7000 ffff83101d825aa8
(XEN) ffff82d080844b60 ffff82d080231e8f ffff82d080844b60 ffff83101d825aa8
(XEN) ffff8300621a7000 0000000000000001 ffff82d0801e6d00 ffff82d080402180
(XEN) 0f0f0f0f0f0f0f0f 00ff00ff00ff00ff 0000000000000000 000000000000003f
(XEN) 0000000000000000 0000000000000003 0000000000000040 00000000000000e0
(XEN) ffff82d08083a9f8 000000fd00000000 ffff82d08012e062 000000000000e008
(XEN) 0000000000000246 ffff8340253dfe00 0000000000000000 ffff83101d825000
(XEN) ffff8300621a7000 ffff832027774f60 0000000000000000 ffff83101d825000
(XEN) ffff82d0801e7d54 0000000000000000 ffff8300621a7000 ffff833dfc4c9880
(XEN) ffff82d0801ec833 0000000000000000 ffff8300621a7000 0000000000000000
(XEN) ffff82d080206e68 ffff8300621a7000 ffff82d0801c7798 ffff8300621a7000
(XEN) ffff82d0801059c4 ffff832027774040 0000000000000000 0000000000000001
(XEN) Xen call trace:
(XEN) [<ffff82d0801f0352>] vmx.c#arch/x86/hvm/vmx/vmx.o.unlikely+0x13a/0x1a8
(XEN) [<ffff82d080161920>] domain.c#__context_switch+0xc0/0x450
(XEN) [<ffff82d080122ee2>] sched_credit.c#csched_vcpu_wake+0x2b2/0x4c0
(XEN) [<ffff82d080166d52>] __sync_local_execstate+0x32/0x60
(XEN) [<ffff82d0801e6d00>] vmcs.c#__vmx_clear_vmcs+0/0xe0
(XEN) [<ffff82d08018d925>] invalidate_interrupt+0x25/0x70
(XEN) [<ffff82d0801706cd>] do_IRQ+0x28d/0x670
(XEN) [<ffff82d08012b627>] vcpu_wake+0x127/0x380
(XEN) [<ffff82d0801e6d00>] vmcs.c#__vmx_clear_vmcs+0/0xe0
(XEN) [<ffff82d080231e8f>] common_interrupt+0x5f/0x70
(XEN) [<ffff82d0801e6d00>] vmcs.c#__vmx_clear_vmcs+0/0xe0
(XEN) [<ffff82d08012e062>] on_selected_cpus+0xb2/0xd0
(XEN) [<ffff82d0801e7d54>] vmx_vmcs_try_enter+0x74/0xa0
(XEN) [<ffff82d0801ec833>] vmx.c#vmx_vcpu_update_eptp+0x43/0xb0
(XEN) [<ffff82d080206e68>] altp2m_vcpu_destroy+0x68/0xa0
(XEN) [<ffff82d0801c7798>] hvm_vcpu_destroy+0x68/0x90
(XEN) [<ffff82d0801059c4>] domain.c#complete_domain_destroy+0x54/0x1a0
(XEN) [<ffff82d0801209c0>] rcupdate.c#rcu_process_callbacks+0xa0/0x1d0
(XEN) [<ffff82d08012d9ec>] softirq.c#__do_softirq+0x5c/0x90
(XEN) [<ffff82d08012d9ec>] softirq.c#__do_softirq+0x5c/0x90
(XEN) [<ffff82d080161695>] domain.c#idle_loop+0x25/0x50
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 23:
(XEN) Xen BUG at ...3rd_src/xen-4.8.2/xen/include/asm/hvm/vmx/vmx.h:394
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

Our environment is :
   CPU: intel xeon E52620 2.40GHz with 24 core,
memory : 256G,
SSD hard disk.
Host machine: suse12
xen_version: 4.8.2
The VM is Win7 OS with 2G memory

The /etc/default/grub file content is:
GRUB_BACKGROUND=/boot/grub2/themes/SLE/background.png
GRUB_THEME=/boot/grub2/themes/SLE/theme.txt
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
GRUB_DISABLE_OS_PROBER="true"
GRUB_ENABLE_CRYPTODISK="n"
GRUB_CMDLINE_LINUX_XEN="crashkernel=1024M,high crashkernel=128M,low"
GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=174080M,max:174080M dom0_max_vcpus=24 hap_1gb=false hap_2mb=false altp2m=1 flask_enforcing=1 console=vga,com1 com1=115200 loglvl=all"

Could you please help us:what the problem is ?

Best regards

发件人: Chenjia (C)
发送时间: 2018年6月14日 10:26
收件人: xen-devel@lists.xenproject.org
抄送: 'Shentao (Terry)' <shentao8@huawei.com>; wangxu (R) <wangxu0@huawei.com>; zhaobingjian <zhaobingjian@huawei.com>
主题: Is there a faster way to restore Virtual machine status in Xen?

Dear XEN expert：
            We meet some problem in our project: In our previous project, we use KVM, and we do some job like this:

We create KVM snapshot by “virsh snapshot-create $DomainName $SnapshotXml”, then do following job:
While(1)
{
Run “virsh snapshot-revert $DomainName  $Snapshot --running --force”
Do some job in 30 secends
}

            Now our project is move to Xen, so we need to do same thing like in KVM, but we found that there is no “Snapshot” in xen , so we change the job like this in xen:
            While(1)
{
                        Run “xl destroy win7_checkpointFile”
                        Run “xl restore  win7_checkpointFile”
                        Do some job in 30 secends
}

            We found that” xl destroy “and “xl restore” spend 10 times longer than “virsh snapshot-revert”,  it is unacceptable in our project

            So our question is that: Is there a faster way to restore Virtual machine status in Xen?

                Our environment:
            CPU: intel xeon E52620 2.40GHz with 24 core,
memory : 256G,
SSD hard disk.
Host machine: suse12
xen_version: 4.8.2
The VM is Win7 OS with 2G memory

Best regards

[-- Attachment #1.2: Type: text/html, Size: 19810 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 19+ messages in thread