Re: [Xen-devel] Re: [Xen-users] svm.c:83:d917 Bad instruction length 0

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

Realistically you're not likely to get much help with this type of issue on
3.1 branch since it is no longer being maintained. Reproducing it on tip of
3.2-testing would be more interesting since will be doing another release
from that branch in the next few weeks. We'd also need more details on the
repro scenario.

 -- Keir

On 8/8/08 20:14, "Russ Blaine" <russell.blaine@xxxxxxx> wrote:

> [moving this thread over to xen-devel]
> 
> Debug keys output on the crashed domain is:
> 
> (xVM) svm.c:77:d3 Bad instruction length 0
> (xVM) domain_crash called from svm.c:78
> (xVM) Domain 3 (vcpu#0) crashed on cpu#1:
> (xVM) ----[ Xen-3.1.4-xvm  x86_64  debug=n  Not tainted ]----
> (xVM) CPU:    1
> (xVM) RIP:    001b:[<0000000072bcaffa>]
> (xVM) RFLAGS: 0000000000000246   CONTEXT: hvm
> (xVM) rax: 0000000000040f12   rbx: 0000000001010800   rcx: 0000000000002001
> (xVM) rdx: 00000000078bfbff   rsi: 0000000072bcaf84   rdi: 0000000000000002
> (xVM) rbp: 000000000075f1b0   rsp: 000000000075f190   r8:  0000000000000000
> (xVM) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (xVM) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (xVM) r15: 0000000000000000   cr0: 000000008001003b   cr4: 00000000000006b9
> (xVM) cr3: 000000007fab7280   cr2: 0000000072c353bc
> (xVM) ds: 732f   es: ffff   fs: ffff   gs: bbff   ss: 0023   cs: 001b
> (xVM) Guest stack trace from rbp=000000000075f1b0:
> (xVM)  72c333d472bcac5f ????????????????
> (xVM) Xen stack trace from rsp=0000000089b8cb48:
> (xVM)    9090f460841b6124 000004a080000000 0000000084e2b1f8
> (xVM)    0000000000000005 89b8cbbc00000001 00000000816a1632
> (xVM)    72c353bc84ab51f0 000000006b12f225 c03961a800000000
> (xVM)    0000000089b8cd64 841b613089b8cbc8 00000000845bf368
> (xVM)    0000000000000000 800000006b12f225 89b8cc08841b3fe4
> (xVM)    00000000816a250d 9090f46072c353bc 0000000084ab51f0
> (xVM)    89b8cc6089b8cd64 c03961a884ab9a90 000000019090f460
> (xVM)    0000000500000000 000007d06b12f8a4 9090f46000000800
> (xVM)    8169f99f89b8ccd0 72c353bc00000000 84ab51f0c03961a8
> (xVM)    9090f46000000000 89b8cc6089b8cd64 0000010000000000
> (xVM)    00000110c03961a8 9090f46000000000 81713802c0484878
> (xVM)    9090f4606b12f8a4 0000000089b8cd4c c03961a880354000
> (xVM)    0000000000000000 8443ee008166e9be 89b8cd4c000000b2
> (xVM)    badb0d00816c12c9 8f27d19000000000 8f27d17884ab9a90
> (xVM)    000201e08f280418 0000000084ab9a90 8183873f00000000
> (xVM)    89b8ccc80000020c 84ab523000000000 84e2d3186a7fd867
> (xVM)    0000001889b8cce0 816c1fff89b8cd4c 9090f46072c353bc
> (xVM)    84ab51f000000000 84e2d31889b8cd64 0000000072c353bc
> (xVM)    89b8ccfc0075f23c 0000000000000110 84ab5020c03961a8
> (xVM)    0000010084e2d318 000000209090f460 84ab9a9084ab5230
> (xVM) Xen call trace:
> (xVM)    [<00000000816a272d>] ???
> (xVM)
> 
> 
> Trolle Selander wrote:
>> The easiest (*cough*) way is usually to put in some code before the
>> domain_crash(curr->domain) that dumps the bytes around the eip, but of
>> course that requires that you rebuild xen from source. One fairly
>> painless thing that you could do to at least get a hint of what might be
>> going on is to set on_crash = 'preserve' in the VM configuration file.
>> That way, after it's crashed, you can do an "xm debug-key v" and get
>> some information about the last vmexit, which will at least tell us what
>> type of instruction it was that caused the vmexit.
>> 
>> On Tue, Aug 5, 2008 at 1:39 AM, James Harper
>> <james.harper@xxxxxxxxxxxxxxxx <mailto:james.harper@xxxxxxxxxxxxxxxx>>
>> wrote:
>> 
>>> 
>>> In 3.2.2-rc2-pre, an instruction length of 0 doesn't cause a guest
>>     crash,
>>> but rather a retry of the instruction. This was introduced in cs
>>     16898.
>>> That said,  in 3.2 and older svm.c has a bunch of special case
>>     emulation
>>> code for system instructions, some of which is quite
>>     incomplete/incorrect.
>>> 3.3 will be much improved in this regard. In any case, a dump of the
>>> instruction bytes surrounding the eip would be necessary to determine
>>     what
>>> the cause was in this particular case.
>>> 
>> 
>>     How easy is it to get that information?
>> 
>>     The annoying thing in this case is that it worked under 3.1.[12].
>> 
>>     Thanks
>> 
>>     James
>> 
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-users



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users