[Fedora-xen] KVM: unhandled exception

[Avi Kivity]

John Summerfield wrote:
> Avi Kivity wrote:
>> John Summerfield wrote:
>>> [root at potoroo ~]# /usr/bin/qemu-kvm -M pc -m 128 -smp 1 -monitor pty 
>>> -no-acpi -boot c -hda /var/lib/xen/images/rto-test.img -net 
>>> nic,macaddr=00:16:3e:31:8a:8f,vlan=0 -net tap,fd=13,script=,vlan=0 
>>> -usb -usbdevice tablet -vnc 0.0.0.0:0
>>> char device redirected to /dev/pts/35
>>> unhandled vm exit:  0x9
>>> rax 000000000000001f rbx 000000000003f530 rcx 00000000000000ff rdx 
>>> 000000000000001f
>>> rsi 0000000000000000 rdi 0000000000000063 rsp 000000000003f40c rbp 
>>> 000000000003f458
>>> r8  0000000000000000 r9  0000000000000000 r10 0000000000000000 r11 
>>> 0000000000000000
>>> r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 
>>> 0000000000000000
>>> rip 000000008051ecc3 rflags 00010246
>>> cs 0008 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0)
>>> ds 0023 (00000000/ffffffff p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0)
>>> es 0023 (00000000/ffffffff p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0)
>>> ss 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
>>> fs 0030 (ffdff000/00001fff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
>>> gs 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0)
>>> tr 0028 (80042000/000020ab p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0)
>>> ldt 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
>>> gdt 8003f000/3ff
>>> idt 8003f400/7ff
>>> cr0 e0000011 cr2 63 cr3 305000 cr4 20 cr8 0 efer 0
>>> Aborted
>>> [root at potoroo ~]#
>>>
>>>
>>> I created the file /var/lib/xen/images/rto-test.img by installing 
>>> Windows XP to the point it reboots.
>>>
>>
>> Did you also install it with -no-acpi?  What happens if you drop that 
>> option?
>>
>
> That commandline is copied from virt-manager's log, where it was 
> accompanied by similar, maybe exactly the same, registers dump and the 
> same error.
>
>
> What I'm seeking is information about what the error means; without it 
> users have almost no chance of fixing the problem themselves.
>
>

Well, the guest executed a hardware context switch.  Windows does this 
sometimes on the way to a blue screen as a means to get into a known 
state.  VT (and SVM) don't support hardware context switching, hence the 
dump.


> Without "-no-acpi" it runs at 105% or so CPU. vncviewer::5900 connects 
> but does not open a window.
> [root at potoroo ~]# lsof -i | grep -E '*:5[0-9]{3}\>'
> xinetd    2180    root    5u  IPv6   7547       TCP *:5902 (LISTEN)
> Xvnc      2456    root    5u  IPv4   8354       TCP *:5966 (LISTEN)
> Xvnc      2456    root    6u  IPv4   8355       TCP *:5866 (LISTEN)
> Xvnc      2456    root   48u  IPv4  22337       TCP 
> localhost.localdomain:5966->localhost.localdomain:47032 (ESTABLISHED)
> Xvnc      2500  summer    5u  IPv4   8473       TCP *:5903 (LISTEN)
> Xvnc      2500  summer    6u  IPv4   8474       TCP *:5803 (LISTEN)
> vncviewer 5533  summer    4u  IPv4  22336       TCP 
> localhost.localdomain:47032->localhost.localdomain:5966 (ESTABLISHED)
> qemu-kvm  5604    root    8u  IPv4  22589       TCP *:5900 (LISTEN)
> vncviewer 5615    root    4u  IPv4  22608       TCP 
> localhost.localdomain:34608->localhost.localdomain:5900 (ESTABLISHED)
> [root at potoroo ~]#
>

Can you try with upstream kvm (from kvm.qumranet.com)?  Though I doubt 
it's a problem with F8's kvm as XP is such a widely used guest.

-- 
error compiling committee.c: too many arguments to function