Does anyone know what a ''svm.c:83:d917 Bad instruction length 0'' crash is? It''s what I''m getting when trying to use Windows 2008. I finally got it installed but it is still crashing randomly with that error. Xen is 3.2.1-2 from Debian Lenny, running on an amd64 system. Windows 3008 is 32 bit. Thanks James (XEN) svm.c:83:d917 Bad instruction length 0 (XEN) domain_crash called from svm.c:84 (XEN) Domain 917 (vcpu#0) crashed on cpu#1: (XEN) ----[ Xen-3.2-1 x86_64 debug=n Not tainted ]---- (XEN) CPU: 1 (XEN) RIP: 001b:[<000000007302affa>] (XEN) RFLAGS: 0000000000000246 CONTEXT: hvm (XEN) rax: 0000000000040f33 rbx: 0000000000000800 rcx: 0000000000002001 (XEN) rdx: 000000000789fbff rsi: 000000007302af84 rdi: 0000000000000002 (XEN) rbp: 0000000000a3f624 rsp: 0000000000a3f604 r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 000000008001003b cr4: 00000000000006b9 (XEN) cr3: 000000001f834280 cr2: 00000000730953bc (XEN) ds: 0023 es: 0023 fs: 003b gs: 0000 ss: 0023 cs: 001b _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Trolle Selander
2008-Aug-04 11:30 UTC
Re: [Xen-users] svm.c:83:d917 Bad instruction length 0
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. On Mon, Aug 4, 2008 at 1:54 AM, James Harper <james.harper@bendigoit.com.au>wrote:> Does anyone know what a ''svm.c:83:d917 Bad instruction length 0'' crash > is? It''s what I''m getting when trying to use Windows 2008. I finally got > it installed but it is still crashing randomly with that error. Xen is > 3.2.1-2 from Debian Lenny, running on an amd64 system. Windows 3008 is > 32 bit. > > Thanks > > James > > (XEN) svm.c:83:d917 Bad instruction length 0 > (XEN) domain_crash called from svm.c:84 > (XEN) Domain 917 (vcpu#0) crashed on cpu#1: > (XEN) ----[ Xen-3.2-1 x86_64 debug=n Not tainted ]---- > (XEN) CPU: 1 > (XEN) RIP: 001b:[<000000007302affa>] > (XEN) RFLAGS: 0000000000000246 CONTEXT: hvm > (XEN) rax: 0000000000040f33 rbx: 0000000000000800 rcx: > 0000000000002001 > (XEN) rdx: 000000000789fbff rsi: 000000007302af84 rdi: > 0000000000000002 > (XEN) rbp: 0000000000a3f624 rsp: 0000000000a3f604 r8: > 0000000000000000 > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > 0000000000000000 > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > 0000000000000000 > (XEN) r15: 0000000000000000 cr0: 000000008001003b cr4: > 00000000000006b9 > (XEN) cr3: 000000001f834280 cr2: 00000000730953bc > (XEN) ds: 0023 es: 0023 fs: 003b gs: 0000 ss: 0023 cs: 001b > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > In 3.2.2-rc2-pre, an instruction length of 0 doesn''t cause a guestcrash,> but rather a retry of the instruction. This was introduced in cs16898.> That said, in 3.2 and older svm.c has a bunch of special caseemulation> code for system instructions, some of which is quiteincomplete/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 determinewhat> 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@lists.xensource.com http://lists.xensource.com/xen-users
Trolle Selander
2008-Aug-05 14:56 UTC
Re: [Xen-users] svm.c:83:d917 Bad instruction length 0
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@bendigoit.com.au>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@lists.xensource.com http://lists.xensource.com/xen-users
We are seeing the same domain crash with a 32-bit win2008 guest under Solaris xen. I''ll rebuild xen to dump out the insns in question... 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@bendigoit.com.au <mailto:james.harper@bendigoit.com.au>> > 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@lists.xensource.com > http://lists.xensource.com/xen-users-- ----------------------------------------------------- Russ Blaine | Solaris Kernel | russell.blaine@sun.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Russ Blaine
2008-Aug-08 19:14 UTC
[Xen-devel] Re: [Xen-users] svm.c:83:d917 Bad instruction length 0
[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@bendigoit.com.au <mailto:james.harper@bendigoit.com.au>> > 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@lists.xensource.com > http://lists.xensource.com/xen-users-- ----------------------------------------------------- Russ Blaine | Solaris Kernel | russell.blaine@sun.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Aug-08 19:22 UTC
Re: [Xen-devel] Re: [Xen-users] svm.c:83:d917 Bad instruction length 0
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@sun.com> 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@bendigoit.com.au <mailto:james.harper@bendigoit.com.au>> >> 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@lists.xensource.com >> http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Russ Blaine
2008-Aug-08 19:35 UTC
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@sun.com> 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@bendigoit.com.au <mailto:james.harper@bendigoit.com.au>> >>> 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@lists.xensource.com >>> http://lists.xensource.com/xen-users > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users-- ----------------------------------------------------- Russ Blaine | Solaris Kernel | russell.blaine@sun.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2008-Aug-11 07:10 UTC
Re: [Xen-devel] Re: [Xen-users] svm.c:83:d917 Bad instruction length 0
We had reports on this (against 3.2.0) too, and this ought to be fixed in 3.2.2 (with c/s 16898, closely after 3.2.1 released) - the decoding of instructions starting close to a page boundary was broken. Jan>>> Russ Blaine <russell.blaine@sun.com> 08.08.08 21:35 >>>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@sun.com> 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@bendigoit.com.au <mailto:james.harper@bendigoit.com.au>> >>> 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@lists.xensource.com >>> http://lists.xensource.com/xen-users > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users-- ----------------------------------------------------- Russ Blaine | Solaris Kernel | russell.blaine@sun.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2008-Aug-11 07:25 UTC
RE: [Xen-devel] Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0
> We had reports on this (against 3.2.0) too, and this ought to be fixedin> 3.2.2 (with c/s 16898, closely after 3.2.1 released) - the decoding of > instructions starting close to a page boundary was broken. JanI''ve just applied 16898 to the Debian sources for 3.2.1 and am building now... do you remember if there were any other dependencies? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2008-Aug-11 07:34 UTC
RE: [Xen-devel] Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0
>>> "James Harper" <james.harper@bendigoit.com.au> 11.08.08 09:25 >>> >> We had reports on this (against 3.2.0) too, and this ought to be fixed >in >> 3.2.2 (with c/s 16898, closely after 3.2.1 released) - the decoding of >> instructions starting close to a page boundary was broken. Jan > >I''ve just applied 16898 to the Debian sources for 3.2.1 and am building >now... do you remember if there were any other dependencies?I don''t recall any. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Russ Blaine
2008-Aug-12 17:15 UTC
Re: [Xen-devel] Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0
I traced the issue to __get_instruction_length_from_list() failing to copy the instruction from the guest. AMD pointed out the relevant changeset, and with that changeset ported to our 3.1.4-based implementation, win 2008 can now boot completely without crashing the domain. Thanks... Jan Beulich wrote:>>>> "James Harper" <james.harper@bendigoit.com.au> 11.08.08 09:25 >>> >>> We had reports on this (against 3.2.0) too, and this ought to be fixed >> in >>> 3.2.2 (with c/s 16898, closely after 3.2.1 released) - the decoding of >>> instructions starting close to a page boundary was broken. Jan >> I''ve just applied 16898 to the Debian sources for 3.2.1 and am building >> now... do you remember if there were any other dependencies? > > I don''t recall any. Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- ----------------------------------------------------- Russ Blaine | Solaris Kernel | russell.blaine@sun.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2008-Aug-19 01:14 UTC
RE: [Xen-devel] Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0
> > > We had reports on this (against 3.2.0) too, and this ought to befixed> in > > 3.2.2 (with c/s 16898, closely after 3.2.1 released) - the decodingof> > instructions starting close to a page boundary was broken. Jan > > I''ve just applied 16898 to the Debian sources for 3.2.1 and ambuilding> now... do you remember if there were any other dependencies? >I finally got a chance to reboot and test this. I would normally get a crash before I am able to log in, but with 16898 applied I am able to log in and join the domain, so I think it''s fixed. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel