| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [Xen-users] svm.c:83:d917 Bad instruction length 0
The original poster sees the issues on 3.2.1-2 / Debian Lenny. I'm talking with
some folks at AMD to see if they can help investigate. In the meantime, I'll be
trying to gather some more useful data about the crashing insn.
- Russ
Keir Fraser wrote:
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
--
-----------------------------------------------------
Russ Blaine | Solaris Kernel | russell.blaine@xxxxxxx
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home