* Doamin crash when trying to install disk encryption (PointSec) on Windows HVM
@ 2009-04-22 8:50 Tom Rotenberg
2009-04-22 10:53 ` Keir Fraser
0 siblings, 1 reply; 43+ messages in thread
From: Tom Rotenberg @ 2009-04-22 8:50 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1908 bytes --]
Hi all,
i am trying to install the disk encryption software: 'PointSec', on a
Windows HVM. After the product is installed, in my second reboot, when the
PointSec is trying to load is UI, the domain is crashing, with the following
error:
(XEN) HVM2: Booting from Hard Disk...
(XEN) HVM2: Booting from 0000:7c00
(XEN) realmode.c:115:d2 Failed to emulate insn.
(XEN) realmode.c:165:d2 Real-mode emulation failed @ 1eae:00000787: 0f 00 d0
e4 70 0c
(XEN) domain_crash called from realmode.c:166
(XEN) Domain 2 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: 1eae:[<0000000000000787>]
(XEN) RFLAGS: 0000000000004046 CONTEXT: hvm guest
(XEN) rax: 0000000000000000 rbx: 0000000000000007 rcx: 0000000000100000
(XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000
(XEN) rbp: 0000000000008ebf rsp: 0000000000017a5e r8: 0000000000000000
(XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000
(XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000
(XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000
(XEN) cr3: 0000000000000000 cr2: 0000000000000000
(XEN) ds: 0040 es: 0080 fs: 0040 gs: 0040 ss: 2112 cs: 1eae
To me, it looks like the xen real-mode emulator fails to emulate the "LLDT"
instruction.
I disassembled the code (as reported from the real-mode error message), and
it looks like this:
LLDT AX
IN AL, 70
OR AL, 8B
AFAIK, the PointSec is trying to load his UI (which is probably coded in
realmode) in this stage, and i guess that some of the instrctions he uses
aren't emulated in Xen.
I am using xen-unstable, changeset: 19553 (from April 16), and the machione
i am working on, is a Lenovo T500.
Can someone please help me with this, as i am not really familiar with the
real mode emulation code?
Thanks,
Tom
[-- Attachment #1.2: Type: text/html, Size: 2132 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 8:50 Doamin crash when trying to install disk encryption (PointSec) on Windows HVM Tom Rotenberg @ 2009-04-22 10:53 ` Keir Fraser 2009-04-22 11:18 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-22 10:53 UTC (permalink / raw) To: Tom Rotenberg, xen-devel@lists.xensource.com [-- Attachment #1: Type: text/plain, Size: 547 bytes --] On 22/04/2009 09:50, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > AFAIK, the PointSec is trying to load his UI (which is probably coded in > realmode) in this stage, and i guess that some of the instrctions he uses > aren't emulated in Xen. > > I am using xen-unstable, changeset: 19553 (from April 16), and the machione i > am working on, is a Lenovo T500. > > Can someone please help me with this, as i am not really familiar with the > real mode emulation code? We don't emulate LLDT at the moment. Try the attached patch. -- Keir [-- Attachment #2: 00-lldt --] [-- Type: application/octet-stream, Size: 1015 bytes --] diff -r cdc044f665dc xen/arch/x86/x86_emulate/x86_emulate.c --- a/xen/arch/x86/x86_emulate/x86_emulate.c Wed Apr 22 11:26:37 2009 +0100 +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Wed Apr 22 11:52:15 2009 +0100 @@ -172,7 +172,7 @@ static uint8_t twobyte_table[256] = { /* 0x00 - 0x07 */ - 0, ImplicitOps|ModRM, 0, 0, 0, 0, ImplicitOps, 0, + SrcMem16|ModRM, ImplicitOps|ModRM, 0, 0, 0, 0, ImplicitOps, 0, /* 0x08 - 0x0F */ ImplicitOps, ImplicitOps, 0, 0, 0, ImplicitOps|ModRM, 0, 0, /* 0x10 - 0x17 */ @@ -3440,6 +3440,14 @@ twobyte_insn: switch ( b ) { + case 0x00: /* Grp6 */ + fail_if((modrm_reg & 7) != 2); + generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1); + generate_exception_if(!mode_ring0(), EXC_GP, 0); + if ( (rc = load_seg(x86_seg_ldtr, src.val, ctxt, ops)) != 0 ) + goto done; + break; + case 0x01: /* Grp7 */ { struct segment_register reg; unsigned long base, limit, cr0, cr0w; [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 10:53 ` Keir Fraser @ 2009-04-22 11:18 ` Tom Rotenberg 2009-04-22 11:50 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-22 11:18 UTC (permalink / raw) To: Keir Fraser; +Cc: xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 1873 bytes --] Keir, I have applied your patch, and it seemed to work. However, the domain still crashes, and now it looks like it's because of the 'LTR' instruction. The (new) error i am receiving is: (XEN) HVM1: Booting from Hard Disk... (XEN) HVM1: Booting from 0000:7c00 (XEN) realmode.c:115:d1 Failed to emulate insn. (XEN) realmode.c:165:d1 Real-mode emulation failed @ 1eae:00000797: 0f 00 d8 66 b8 8e (XEN) domain_crash called from realmode.c:166 (XEN) Domain 1 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: 1eae:[<0000000000000797>] (XEN) RFLAGS: 0000000000004086 CONTEXT: hvm guest (XEN) rax: 0000000000000050 rbx: 0000000000000007 rcx: 0000000000100000 (XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) rbp: 0000000000008ebf rsp: 0000000000017a5e r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 (XEN) cr3: 0000000000000000 cr2: 0000000000000000 (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 1eae Tom 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > On 22/04/2009 09:50, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > AFAIK, the PointSec is trying to load his UI (which is probably coded in > > realmode) in this stage, and i guess that some of the instrctions he uses > > aren't emulated in Xen. > > > > I am using xen-unstable, changeset: 19553 (from April 16), and the > machione i > > am working on, is a Lenovo T500. > > > > Can someone please help me with this, as i am not really familiar with > the > > real mode emulation code? > > We don't emulate LLDT at the moment. Try the attached patch. > > -- Keir > > [-- Attachment #1.2: Type: text/html, Size: 2488 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 11:18 ` Tom Rotenberg @ 2009-04-22 11:50 ` Keir Fraser 2009-04-22 12:39 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-22 11:50 UTC (permalink / raw) To: Tom Rotenberg; +Cc: xen-devel@lists.xensource.com [-- Attachment #1: Type: text/plain, Size: 338 bytes --] On 22/04/2009 12:18, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > Keir, > > I have applied your patch, and it seemed to work. However, the domain still > crashes, and now it looks like it's because of the 'LTR' instruction. Try the attached patch. It replaces the one I sent last time, and emulates both LLDT and LTR. -- Keir [-- Attachment #2: 00-lldt --] [-- Type: application/octet-stream, Size: 3281 bytes --] diff -r cdc044f665dc xen/arch/x86/x86_emulate/x86_emulate.c --- a/xen/arch/x86/x86_emulate/x86_emulate.c Wed Apr 22 11:26:37 2009 +0100 +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Wed Apr 22 12:48:37 2009 +0100 @@ -172,7 +172,7 @@ static uint8_t twobyte_table[256] = { /* 0x00 - 0x07 */ - 0, ImplicitOps|ModRM, 0, 0, 0, 0, ImplicitOps, 0, + SrcMem16|ModRM, ImplicitOps|ModRM, 0, 0, 0, 0, ImplicitOps, 0, /* 0x08 - 0x0F */ ImplicitOps, ImplicitOps, 0, 0, 0, ImplicitOps|ModRM, 0, 0, /* 0x10 - 0x17 */ @@ -971,8 +971,8 @@ struct { uint32_t a, b; } desc; unsigned long val; uint8_t dpl, rpl, cpl; - uint32_t new_desc_b; - int rc, fault_type = EXC_TS; + uint32_t new_desc_b, a_flag = 0x100; + int rc, fault_type = EXC_GP; /* NULL selector? */ if ( (sel & 0xfffc) == 0 ) @@ -983,8 +983,8 @@ return ops->write_segment(seg, &segr, ctxt); } - /* LDT descriptor must be in the GDT. */ - if ( (seg == x86_seg_ldtr) && (sel & 4) ) + /* System segment descriptors must reside in the GDT. */ + if ( !is_x86_user_segment(seg) && (sel & 4) ) goto raise_exn; if ( (rc = ops->read_segment(x86_seg_ss, &ss, ctxt)) || @@ -1013,8 +1013,8 @@ goto raise_exn; } - /* LDT descriptor is a system segment. All others are code/data. */ - if ( (desc.b & (1u<<12)) == ((seg == x86_seg_ldtr) << 12) ) + /* System segments must have the system flag (S) set. */ + if ( (desc.b & (1u<<12)) == (!is_x86_user_segment(seg) << 12) ) goto raise_exn; dpl = (desc.b >> 13) & 3; @@ -1043,6 +1043,12 @@ if ( (desc.b & (15u<<8)) != (2u<<8) ) goto raise_exn; goto skip_accessed_flag; + case x86_seg_tr: + /* Available TSS system segment? */ + if ( (desc.b & (15u<<8)) != (9u<<8) ) + goto raise_exn; + a_flag = 0x200; /* busy flag */ + break; default: /* Readable code or data segment? */ if ( (desc.b & (5u<<9)) == (4u<<9) ) @@ -1055,8 +1061,8 @@ } /* Ensure Accessed flag is set. */ - new_desc_b = desc.b | 0x100; - rc = ((desc.b & 0x100) ? X86EMUL_OKAY : + new_desc_b = desc.b | a_flag; + rc = ((desc.b & a_flag) ? X86EMUL_OKAY : ops->cmpxchg( x86_seg_none, desctab.base + (sel & 0xfff8) + 4, &desc.b, &new_desc_b, 4, ctxt)); @@ -1066,7 +1072,7 @@ return rc; /* Force the Accessed flag in our local copy. */ - desc.b |= 0x100; + desc.b |= a_flag; skip_accessed_flag: segr.base = (((desc.b << 0) & 0xff000000u) | @@ -3440,6 +3446,15 @@ twobyte_insn: switch ( b ) { + case 0x00: /* Grp6 */ + fail_if((modrm_reg & 6) != 2); + generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1); + generate_exception_if(!mode_ring0(), EXC_GP, 0); + if ( (rc = load_seg((modrm_reg & 1) ? x86_seg_tr : x86_seg_ldtr, + src.val, ctxt, ops)) != 0 ) + goto done; + break; + case 0x01: /* Grp7 */ { struct segment_register reg; unsigned long base, limit, cr0, cr0w; [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 11:50 ` Keir Fraser @ 2009-04-22 12:39 ` Tom Rotenberg 2009-04-22 12:59 ` Keir Fraser 2009-04-22 13:12 ` Tim Deegan 0 siblings, 2 replies; 43+ messages in thread From: Tom Rotenberg @ 2009-04-22 12:39 UTC (permalink / raw) To: Keir Fraser; +Cc: xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 4257 bytes --] Keir, I have tried your latest patch, and it looks like now it passes the emulation problem. However, now the domain crashes with the following error: (XEN) HVM1: Booting from 0000:7c00 (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state (0). (XEN) ************* VMCS Area ************** (XEN) *** Guest State *** (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, gh_mask=ffffffffffffffff (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, gh_mask=ffffffffffffffff (XEN) CR3: actual=0x000000000a213a20, target_count=0 (XEN) target0=0000000000000000, target1=0000000000000000 (XEN) target2=0000000000000000, target3=0000000000000000 (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = 0x000000000000002a (0x000000000000002a) (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = 0x0000000000000400 (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, base=0x0000000000200000 (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, base=0x000000000020ba62 (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 (XEN) GDTR: limit=0x00001dd8, base=0x0000000000200000 (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, base=0x0000000000000000 (XEN) IDTR: limit=0x00000188, base=0x0000000000201df0 (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, base=0x0000000000201ff2 (XEN) Guest PAT = 0x0000000000000000 (XEN) TSC Offset = ffffffe4920110b7 (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 (XEN) Interruptibility=0001 ActivityState=0000 (XEN) *** Host State *** (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 (XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff828c802a8b00 (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 (XEN) CR0=0000000080050033 CR3=000000007cfdc000 CR4=00000000000026f0 (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 (XEN) Host PAT = 0x0000000000000000 (XEN) *** Control State *** (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 (XEN) EntryControls=000011ff ExitControls=0003efff (XEN) ExceptionBitmap=00044080 (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 (XEN) reason=80000021 qualification=00000000 (XEN) IDTVectoring: info=00000000 errcode=00000000 (XEN) TPR Threshold = 0x00 (XEN) EPT pointer = 0x0000000000000000 (XEN) Virtual processor ID = 0x0000 (XEN) ************************************** (XEN) domain_crash called from vmx.c:2218 (XEN) Domain 1 (vcpu#0) crashed on cpu#1: (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- (XEN) CPU: 1 (XEN) RIP: 0060:[<000000000000002a>] (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: 0000000000000000 (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: 0000000000000000 (XEN) cr3: 0000000001443000 cr2: 0000000000000000 (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 Could it be, that the real mode emulation code has a bug? What does this error means? Tom 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > On 22/04/2009 12:18, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > Keir, > > > > I have applied your patch, and it seemed to work. However, the domain > still > > crashes, and now it looks like it's because of the 'LTR' instruction. > > Try the attached patch. It replaces the one I sent last time, and emulates > both LLDT and LTR. > > -- Keir > > [-- Attachment #1.2: Type: text/html, Size: 4950 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 12:39 ` Tom Rotenberg @ 2009-04-22 12:59 ` Keir Fraser 2009-04-22 13:02 ` Keir Fraser 2009-04-22 13:12 ` Tim Deegan 1 sibling, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-22 12:59 UTC (permalink / raw) To: Tom Rotenberg; +Cc: xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 378 bytes --] On 22/04/2009 13:39, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > Could it be, that the real mode emulation code has a bug? What does this error > means? It means we tried to enter VMX mode for the guest, and the processor did some guest state checks (listed in the x86 reference manual vol 3B, section 22.3.1). The TR and LDT state looks okay, so I don¹t think [-- Attachment #1.2: Type: text/html, Size: 908 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 12:59 ` Keir Fraser @ 2009-04-22 13:02 ` Keir Fraser 0 siblings, 0 replies; 43+ messages in thread From: Keir Fraser @ 2009-04-22 13:02 UTC (permalink / raw) To: Tom Rotenberg; +Cc: xen-devel@lists.xensource.com On 22/04/2009 13:59, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: > On 22/04/2009 13:39, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > >> Could it be, that the real mode emulation code has a bug? What does this >> error means? > > It means we tried to enter VMX mode for the guest, and the processor did some > guest state checks (listed in the x86 reference manual vol 3B, section > 22.3.1). The TR and LDT state looks okay, so I don¹t think ..oops, sent too soon... The TR and LDT state looks okay, so I don't think the LLDT/LTR emulation is wrong, or if they are then it's in a subtle way. Probably step one would be to go through the state listed in the crash dump and compare it with the checks listed in the reference manual vol 3B. Then try to work out how the part that is wrong got to be that way. Can be a bit of a pain. :-( I will check in the LLDT/LTR emulation code after 3.4 branches, at least. -- Keir ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 12:39 ` Tom Rotenberg 2009-04-22 12:59 ` Keir Fraser @ 2009-04-22 13:12 ` Tim Deegan 2009-04-22 13:23 ` Tom Rotenberg 1 sibling, 1 reply; 43+ messages in thread From: Tim Deegan @ 2009-04-22 13:12 UTC (permalink / raw) To: Tom Rotenberg; +Cc: xen-devel@lists.xensource.com, Keir Fraser At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: > Keir, > > I have tried your latest patch, and it looks like now it passes the emulation problem. However, now the domain crashes with the following error: > > (XEN) HVM1: Booting from 0000:7c00 > (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state (0). > (XEN) ************* VMCS Area ************** > (XEN) *** Guest State *** > (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, gh_mask=ffffffffffffffff > (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, gh_mask=ffffffffffffffff > (XEN) CR3: actual=0x000000000a213a20, target_count=0 > (XEN) target0=0000000000000000, target1=0000000000000000 > (XEN) target2=0000000000000000, target3=0000000000000000 > (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = 0x000000000000002a (0x000000000000002a) > (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = 0x0000000000000400 Looks like we're trying to VMENTER in virtual 8086 mode but without tidying up the segment state. That could either be the guest entering virtual 8086 mode itself or Xen entering vitrual 8086 mode to emulate real mode, but Xen is always careful to make the segment state agree with Intel's rather strict requrements when it does that. Tim. > (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, base=0x0000000000200000 > (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 > (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, base=0x000000000020ba62 > (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 > (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 > (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 > (XEN) GDTR: limit=0x00001dd8, base=0x0000000000200000 > (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, base=0x0000000000000000 > (XEN) IDTR: limit=0x00000188, base=0x0000000000201df0 > (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, base=0x0000000000201ff2 > (XEN) Guest PAT = 0x0000000000000000 > (XEN) TSC Offset = ffffffe4920110b7 > (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > (XEN) Interruptibility=0001 ActivityState=0000 > (XEN) *** Host State *** > (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > (XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff828c802a8b00 > (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > (XEN) CR0=0000000080050033 CR3=000000007cfdc000 CR4=00000000000026f0 > (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > (XEN) Host PAT = 0x0000000000000000 > (XEN) *** Control State *** > (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > (XEN) EntryControls=000011ff ExitControls=0003efff > (XEN) ExceptionBitmap=00044080 > (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > (XEN) reason=80000021 qualification=00000000 > (XEN) IDTVectoring: info=00000000 errcode=00000000 > (XEN) TPR Threshold = 0x00 > (XEN) EPT pointer = 0x0000000000000000 > (XEN) Virtual processor ID = 0x0000 > (XEN) ************************************** > (XEN) domain_crash called from vmx.c:2218 > (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- > (XEN) CPU: 1 > (XEN) RIP: 0060:[<000000000000002a>] > (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: 0000000000000000 > (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: 0000000000000000 > (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: 0000000000000000 > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 > (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: 0000000000000000 > (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 > > Could it be, that the real mode emulation code has a bug? What does this error means? > > Tom > > 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> > On 22/04/2009 12:18, "Tom Rotenberg" <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> wrote: > > > Keir, > > > > I have applied your patch, and it seemed to work. However, the domain still > > crashes, and now it looks like it's because of the 'LTR' instruction. > > Try the attached patch. It replaces the one I sent last time, and emulates > both LLDT and LTR. > > -- Keir > Content-Description: ATT00001.txt > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 13:12 ` Tim Deegan @ 2009-04-22 13:23 ` Tom Rotenberg 2009-04-22 13:31 ` Tim Deegan 2009-04-22 13:34 ` Keir Fraser 0 siblings, 2 replies; 43+ messages in thread From: Tom Rotenberg @ 2009-04-22 13:23 UTC (permalink / raw) To: Tim Deegan; +Cc: xen-devel@lists.xensource.com, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 5913 bytes --] Tim, so what does it mean? could it be that we have a bug in the real mode emulation, which causes the segment state to be invalid (maybe it's because of a bug in the patch that Keir made for me, which emulated the LLDT, and the LTR instructions)? Keir suggested to trace back where the problem (segment state) occured, and from there to try and find the bug which caused it. Do u have any better suggestion for solving this? Tom 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: > > Keir, > > > > I have tried your latest patch, and it looks like now it passes the > emulation problem. However, now the domain crashes with the following > error: > > > > (XEN) HVM1: Booting from 0000:7c00 > > (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest > state (0). > > (XEN) ************* VMCS Area ************** > > (XEN) *** Guest State *** > > (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, > gh_mask=ffffffffffffffff > > (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, > gh_mask=ffffffffffffffff > > (XEN) CR3: actual=0x000000000a213a20, target_count=0 > > (XEN) target0=0000000000000000, target1=0000000000000000 > > (XEN) target2=0000000000000000, target3=0000000000000000 > > (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > 0x000000000000002a (0x000000000000002a) > > (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > 0x0000000000000400 > > Looks like we're trying to VMENTER in virtual 8086 mode but without > tidying up the segment state. That could either be the guest entering > virtual 8086 mode itself or Xen entering vitrual 8086 mode to emulate > real mode, but Xen is always careful to make the segment state agree > with Intel's rather strict requrements when it does that. > > Tim. > > > > (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > > (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > base=0x0000000000200000 > > (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > base=0x0000000000200000 > > (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > base=0x000000000020ba62 > > (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > base=0x0000000000200000 > > (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > base=0x0000000000200000 > > (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > base=0x0000000000200000 > > (XEN) GDTR: limit=0x00001dd8, > base=0x0000000000200000 > > (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > base=0x0000000000000000 > > (XEN) IDTR: limit=0x00000188, > base=0x0000000000201df0 > > (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > base=0x0000000000201ff2 > > (XEN) Guest PAT = 0x0000000000000000 > > (XEN) TSC Offset = ffffffe4920110b7 > > (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > > (XEN) Interruptibility=0001 ActivityState=0000 > > (XEN) *** Host State *** > > (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > > (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > > (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > TRBase=ffff828c802a8b00 > > (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > > (XEN) CR0=0000000080050033 CR3=000000007cfdc000 CR4=00000000000026f0 > > (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > > (XEN) Host PAT = 0x0000000000000000 > > (XEN) *** Control State *** > > (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > > (XEN) EntryControls=000011ff ExitControls=0003efff > > (XEN) ExceptionBitmap=00044080 > > (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > > (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > > (XEN) reason=80000021 qualification=00000000 > > (XEN) IDTVectoring: info=00000000 errcode=00000000 > > (XEN) TPR Threshold = 0x00 > > (XEN) EPT pointer = 0x0000000000000000 > > (XEN) Virtual processor ID = 0x0000 > > (XEN) ************************************** > > (XEN) domain_crash called from vmx.c:2218 > > (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > > (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- > > (XEN) CPU: 1 > > (XEN) RIP: 0060:[<000000000000002a>] > > (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > > (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: > 0000000000000000 > > (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: > 0000000000000000 > > (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: > 0000000000000000 > > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > 0000000000000000 > > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > 0000000000000000 > > (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: > 0000000000000000 > > (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > > (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 > > > > Could it be, that the real mode emulation code has a bug? What does this > error means? > > > > Tom > > > > 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com<mailto: > keir.fraser@eu.citrix.com>> > > On 22/04/2009 12:18, "Tom Rotenberg" <tom.rotenberg@gmail.com<mailto: > tom.rotenberg@gmail.com>> wrote: > > > > > Keir, > > > > > > I have applied your patch, and it seemed to work. However, the domain > still > > > crashes, and now it looks like it's because of the 'LTR' instruction. > > > > Try the attached patch. It replaces the one I sent last time, and > emulates > > both LLDT and LTR. > > > > -- Keir > > > > Content-Description: ATT00001.txt > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > -- > Tim Deegan <Tim.Deegan@citrix.com> > Principal Software Engineer, Citrix Systems (R&D) Ltd. > [Company #02300071, SL9 0DZ, UK.] > [-- Attachment #1.2: Type: text/html, Size: 7281 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 13:23 ` Tom Rotenberg @ 2009-04-22 13:31 ` Tim Deegan 2009-04-22 13:34 ` Keir Fraser 1 sibling, 0 replies; 43+ messages in thread From: Tim Deegan @ 2009-04-22 13:31 UTC (permalink / raw) To: Tom Rotenberg; +Cc: xen-devel@lists.xensource.com, Keir Fraser At 14:23 +0100 on 22 Apr (1240410216), Tom Rotenberg wrote: > so what does it mean? could it be that we have a bug in the real mode > emulation, which causes the segment state to be invalid (maybe it's > because of a bug in the patch that Keir made for me, which emulated > the LLDT, and the LTR instructions)? It means probably that Xen doesn't support the guest using virtual 8086 mode. Adding support probably wouldn't be too hard, by treating virtual 8086 mode as a special case of real mode, but I don't have time to look at it right now. Tim. > Keir suggested to trace back where the problem (segment state) > occured, and from there to try and find the bug which caused it. Do u > have any better suggestion for solving this? > > Tom > > 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com<mailto:Tim.Deegan@citrix.com>> > At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: > > Keir, > > > > I have tried your latest patch, and it looks like now it passes the emulation problem. However, now the domain crashes with the following error: > > > > (XEN) HVM1: Booting from 0000:7c00 > > (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state (0). > > (XEN) ************* VMCS Area ************** > > (XEN) *** Guest State *** > > (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, gh_mask=ffffffffffffffff > > (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, gh_mask=ffffffffffffffff > > (XEN) CR3: actual=0x000000000a213a20, target_count=0 > > (XEN) target0=0000000000000000, target1=0000000000000000 > > (XEN) target2=0000000000000000, target3=0000000000000000 > > (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = 0x000000000000002a (0x000000000000002a) > > (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = 0x0000000000000400 > > Looks like we're trying to VMENTER in virtual 8086 mode but without > tidying up the segment state. That could either be the guest entering > virtual 8086 mode itself or Xen entering vitrual 8086 mode to emulate > real mode, but Xen is always careful to make the segment state agree > with Intel's rather strict requrements when it does that. > > Tim. > > > > (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > > (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, base=0x0000000000200000 > > (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 > > (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, base=0x000000000020ba62 > > (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 > > (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 > > (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 > > (XEN) GDTR: limit=0x00001dd8, base=0x0000000000200000 > > (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, base=0x0000000000000000 > > (XEN) IDTR: limit=0x00000188, base=0x0000000000201df0 > > (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, base=0x0000000000201ff2 > > (XEN) Guest PAT = 0x0000000000000000 > > (XEN) TSC Offset = ffffffe4920110b7 > > (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > > (XEN) Interruptibility=0001 ActivityState=0000 > > (XEN) *** Host State *** > > (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > > (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > > (XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff828c802a8b00 > > (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > > (XEN) CR0=0000000080050033 CR3=000000007cfdc000 CR4=00000000000026f0 > > (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > > (XEN) Host PAT = 0x0000000000000000 > > (XEN) *** Control State *** > > (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > > (XEN) EntryControls=000011ff ExitControls=0003efff > > (XEN) ExceptionBitmap=00044080 > > (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > > (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > > (XEN) reason=80000021 qualification=00000000 > > (XEN) IDTVectoring: info=00000000 errcode=00000000 > > (XEN) TPR Threshold = 0x00 > > (XEN) EPT pointer = 0x0000000000000000 > > (XEN) Virtual processor ID = 0x0000 > > (XEN) ************************************** > > (XEN) domain_crash called from vmx.c:2218 > > (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > > (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- > > (XEN) CPU: 1 > > (XEN) RIP: 0060:[<000000000000002a>] > > (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > > (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: 0000000000000000 > > (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: 0000000000000000 > > (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: 0000000000000000 > > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 > > (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: 0000000000000000 > > (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > > (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 > > > > Could it be, that the real mode emulation code has a bug? What does this error means? > > > > Tom > > > > 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com><mailto:keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>>> > > On 22/04/2009 12:18, "Tom Rotenberg" <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com><mailto:tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>>> wrote: > > > > > Keir, > > > > > > I have applied your patch, and it seemed to work. However, the domain still > > > crashes, and now it looks like it's because of the 'LTR' instruction. > > > > Try the attached patch. It replaces the one I sent last time, and emulates > > both LLDT and LTR. > > > > -- Keir > > > > Content-Description: ATT00001.txt > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com> > > http://lists.xensource.com/xen-devel > > > -- > Tim Deegan <Tim.Deegan@citrix.com<mailto:Tim.Deegan@citrix.com>> > Principal Software Engineer, Citrix Systems (R&D) Ltd. > [Company #02300071, SL9 0DZ, UK.] -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 13:23 ` Tom Rotenberg 2009-04-22 13:31 ` Tim Deegan @ 2009-04-22 13:34 ` Keir Fraser 2009-04-22 13:41 ` Tim Deegan 1 sibling, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-22 13:34 UTC (permalink / raw) To: Tom Rotenberg, Tim Deegan; +Cc: xen-devel@lists.xensource.com It could be an issue with the vm86 acceleration, possibly. I'm pretty sure the guest would have to IRET from protected mode to enter vm86 mode itself, and we don't emulate that. Tim: what would we need to do to disable the vm86 acceleration for testing purposes? You suggested not setting VM86_TSS param from hvmloader, but I couldn't convince myself what effect that would actually have as the logic in Xen is non-trivial. -- Keir On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > Tim, > > so what does it mean? could it be that we have a bug in the real mode > emulation, which causes the segment state to be invalid (maybe it's because of > a bug in the patch that Keir made for me, which emulated the LLDT, and the LTR > instructions)? > > Keir suggested to trace back where the problem (segment state) occured, and > from there to try and find the bug which caused it. Do u have any better > suggestion for solving this? > > Tom > > 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> >> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: >>> Keir, >>> >>> I have tried your latest patch, and it looks like now it passes the >>> emulation problem. However, now the domain crashes with the following >>> error: >>> >>> (XEN) HVM1: Booting from 0000:7c00 >>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state >>> (0). >>> (XEN) ************* VMCS Area ************** >>> (XEN) *** Guest State *** >>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, >>> gh_mask=ffffffffffffffff >>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, >>> gh_mask=ffffffffffffffff >>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 >>> (XEN) target0=0000000000000000, target1=0000000000000000 >>> (XEN) target2=0000000000000000, target3=0000000000000000 >>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = >>> 0x000000000000002a (0x000000000000002a) >>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = >>> 0x0000000000000400 >> >> Looks like we're trying to VMENTER in virtual 8086 mode but without >> tidying up the segment state. That could either be the guest entering >> virtual 8086 mode itself or Xen entering vitrual 8086 mode to emulate >> real mode, but Xen is always careful to make the segment state agree >> with Intel's rather strict requrements when it does that. >> >> Tim. >> >> >>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 >>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, >>> base=0x0000000000200000 >>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>> base=0x0000000000200000 >>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, >>> base=0x000000000020ba62 >>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>> base=0x0000000000200000 >>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>> base=0x0000000000200000 >>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>> base=0x0000000000200000 >>> (XEN) GDTR: limit=0x00001dd8, >>> base=0x0000000000200000 >>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, >>> base=0x0000000000000000 >>> (XEN) IDTR: limit=0x00000188, >>> base=0x0000000000201df0 >>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, >>> base=0x0000000000201ff2 >>> (XEN) Guest PAT = 0x0000000000000000 >>> (XEN) TSC Offset = ffffffe4920110b7 >>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 >>> (XEN) Interruptibility=0001 ActivityState=0000 >>> (XEN) *** Host State *** >>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 >>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 >>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 >>> TRBase=ffff828c802a8b00 >>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 >>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 CR4=00000000000026f0 >>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 >>> (XEN) Host PAT = 0x0000000000000000 >>> (XEN) *** Control State *** >>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 >>> (XEN) EntryControls=000011ff ExitControls=0003efff >>> (XEN) ExceptionBitmap=00044080 >>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 >>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 >>> (XEN) reason=80000021 qualification=00000000 >>> (XEN) IDTVectoring: info=00000000 errcode=00000000 >>> (XEN) TPR Threshold = 0x00 >>> (XEN) EPT pointer = 0x0000000000000000 >>> (XEN) Virtual processor ID = 0x0000 >>> (XEN) ************************************** >>> (XEN) domain_crash called from vmx.c:2218 >>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: >>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- >>> (XEN) CPU: 1 >>> (XEN) RIP: 0060:[<000000000000002a>] >>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest >>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: 0000000000000000 >>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: 0000000000000000 >>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: 0000000000000000 >>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 >>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 >>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: 0000000000000000 >>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 >>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 >>> >>> Could it be, that the real mode emulation code has a bug? What does this >>> error means? >>> >>> Tom >>> >>> 2009/4/22 Keir Fraser >>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> >>> On 22/04/2009 12:18, "Tom Rotenberg" >>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> wrote: >>> >>>> Keir, >>>> >>>> I have applied your patch, and it seemed to work. However, the domain still >>>> crashes, and now it looks like it's because of the 'LTR' instruction. >>> >>> Try the attached patch. It replaces the one I sent last time, and emulates >>> both LLDT and LTR. >>> >>> -- Keir >>> >> >> Content-Description: ATT00001.txt >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> >> >> -- >> Tim Deegan <Tim.Deegan@citrix.com> >> Principal Software Engineer, Citrix Systems (R&D) Ltd. >> [Company #02300071, SL9 0DZ, UK.] > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 13:34 ` Keir Fraser @ 2009-04-22 13:41 ` Tim Deegan 2009-04-22 13:52 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Tim Deegan @ 2009-04-22 13:41 UTC (permalink / raw) To: Keir Fraser; +Cc: Tom Rotenberg, xen-devel@lists.xensource.com At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: > It could be an issue with the vm86 acceleration, possibly. I'm pretty sure > the guest would have to IRET from protected mode to enter vm86 mode itself, > and we don't emulate that. Tim: what would we need to do to disable the vm86 > acceleration for testing purposes? You suggested not setting VM86_TSS param > from hvmloader, but I couldn't convince myself what effect that would > actually have as the logic in Xen is non-trivial. Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() will always set the tss bit in the bitmap of segments that aren't safe to enter VM86 with. Tim. > > -- Keir > > On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > Tim, > > > > so what does it mean? could it be that we have a bug in the real mode > > emulation, which causes the segment state to be invalid (maybe it's because of > > a bug in the patch that Keir made for me, which emulated the LLDT, and the LTR > > instructions)? > > > > Keir suggested to trace back where the problem (segment state) occured, and > > from there to try and find the bug which caused it. Do u have any better > > suggestion for solving this? > > > > Tom > > > > 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: > >>> Keir, > >>> > >>> I have tried your latest patch, and it looks like now it passes the > >>> emulation problem. However, now the domain crashes with the following > >>> error: > >>> > >>> (XEN) HVM1: Booting from 0000:7c00 > >>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state > >>> (0). > >>> (XEN) ************* VMCS Area ************** > >>> (XEN) *** Guest State *** > >>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, > >>> gh_mask=ffffffffffffffff > >>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, > >>> gh_mask=ffffffffffffffff > >>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 > >>> (XEN) target0=0000000000000000, target1=0000000000000000 > >>> (XEN) target2=0000000000000000, target3=0000000000000000 > >>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > >>> 0x000000000000002a (0x000000000000002a) > >>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > >>> 0x0000000000000400 > >> > >> Looks like we're trying to VMENTER in virtual 8086 mode but without > >> tidying up the segment state. That could either be the guest entering > >> virtual 8086 mode itself or Xen entering vitrual 8086 mode to emulate > >> real mode, but Xen is always careful to make the segment state agree > >> with Intel's rather strict requrements when it does that. > >> > >> Tim. > >> > >> > >>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > >>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > >>> base=0x000000000020ba62 > >>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) GDTR: limit=0x00001dd8, > >>> base=0x0000000000200000 > >>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > >>> base=0x0000000000000000 > >>> (XEN) IDTR: limit=0x00000188, > >>> base=0x0000000000201df0 > >>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > >>> base=0x0000000000201ff2 > >>> (XEN) Guest PAT = 0x0000000000000000 > >>> (XEN) TSC Offset = ffffffe4920110b7 > >>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > >>> (XEN) Interruptibility=0001 ActivityState=0000 > >>> (XEN) *** Host State *** > >>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > >>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > >>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > >>> TRBase=ffff828c802a8b00 > >>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > >>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 CR4=00000000000026f0 > >>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > >>> (XEN) Host PAT = 0x0000000000000000 > >>> (XEN) *** Control State *** > >>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > >>> (XEN) EntryControls=000011ff ExitControls=0003efff > >>> (XEN) ExceptionBitmap=00044080 > >>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > >>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > >>> (XEN) reason=80000021 qualification=00000000 > >>> (XEN) IDTVectoring: info=00000000 errcode=00000000 > >>> (XEN) TPR Threshold = 0x00 > >>> (XEN) EPT pointer = 0x0000000000000000 > >>> (XEN) Virtual processor ID = 0x0000 > >>> (XEN) ************************************** > >>> (XEN) domain_crash called from vmx.c:2218 > >>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > >>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- > >>> (XEN) CPU: 1 > >>> (XEN) RIP: 0060:[<000000000000002a>] > >>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > >>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: 0000000000000000 > >>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: 0000000000000000 > >>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: 0000000000000000 > >>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > >>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 > >>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: 0000000000000000 > >>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > >>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 > >>> > >>> Could it be, that the real mode emulation code has a bug? What does this > >>> error means? > >>> > >>> Tom > >>> > >>> 2009/4/22 Keir Fraser > >>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> > >>> On 22/04/2009 12:18, "Tom Rotenberg" > >>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> wrote: > >>> > >>>> Keir, > >>>> > >>>> I have applied your patch, and it seemed to work. However, the domain still > >>>> crashes, and now it looks like it's because of the 'LTR' instruction. > >>> > >>> Try the attached patch. It replaces the one I sent last time, and emulates > >>> both LLDT and LTR. > >>> > >>> -- Keir > >>> > >> > >> Content-Description: ATT00001.txt > >>> _______________________________________________ > >>> Xen-devel mailing list > >>> Xen-devel@lists.xensource.com > >>> http://lists.xensource.com/xen-devel > >> > >> > >> -- > >> Tim Deegan <Tim.Deegan@citrix.com> > >> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >> [Company #02300071, SL9 0DZ, UK.] > > > > -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 13:41 ` Tim Deegan @ 2009-04-22 13:52 ` Tom Rotenberg 2009-04-22 13:59 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-22 13:52 UTC (permalink / raw) To: Tim Deegan; +Cc: xen-devel@lists.xensource.com, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 7629 bytes --] So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and re-check it? 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: > > It could be an issue with the vm86 acceleration, possibly. I'm pretty > sure > > the guest would have to IRET from protected mode to enter vm86 mode > itself, > > and we don't emulate that. Tim: what would we need to do to disable the > vm86 > > acceleration for testing purposes? You suggested not setting VM86_TSS > param > > from hvmloader, but I couldn't convince myself what effect that would > > actually have as the logic in Xen is non-trivial. > > Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() will > always set the tss bit in the bitmap of segments that aren't safe to > enter VM86 with. > > Tim. > > > > > -- Keir > > > > On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > > > Tim, > > > > > > so what does it mean? could it be that we have a bug in the real mode > > > emulation, which causes the segment state to be invalid (maybe it's > because of > > > a bug in the patch that Keir made for me, which emulated the LLDT, and > the LTR > > > instructions)? > > > > > > Keir suggested to trace back where the problem (segment state) occured, > and > > > from there to try and find the bug which caused it. Do u have any > better > > > suggestion for solving this? > > > > > > Tom > > > > > > 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > > >> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: > > >>> Keir, > > >>> > > >>> I have tried your latest patch, and it looks like now it passes the > > >>> emulation problem. However, now the domain crashes with the > following > > >>> error: > > >>> > > >>> (XEN) HVM1: Booting from 0000:7c00 > > >>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid > guest state > > >>> (0). > > >>> (XEN) ************* VMCS Area ************** > > >>> (XEN) *** Guest State *** > > >>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, > > >>> gh_mask=ffffffffffffffff > > >>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, > > >>> gh_mask=ffffffffffffffff > > >>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 > > >>> (XEN) target0=0000000000000000, target1=0000000000000000 > > >>> (XEN) target2=0000000000000000, target3=0000000000000000 > > >>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > > >>> 0x000000000000002a (0x000000000000002a) > > >>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > > >>> 0x0000000000000400 > > >> > > >> Looks like we're trying to VMENTER in virtual 8086 mode but without > > >> tidying up the segment state. That could either be the guest entering > > >> virtual 8086 mode itself or Xen entering vitrual 8086 mode to emulate > > >> real mode, but Xen is always careful to make the segment state agree > > >> with Intel's rather strict requrements when it does that. > > >> > > >> Tim. > > >> > > >> > > >>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > > >>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > > >>> base=0x0000000000200000 > > >>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > > >>> base=0x0000000000200000 > > >>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > > >>> base=0x000000000020ba62 > > >>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > > >>> base=0x0000000000200000 > > >>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > > >>> base=0x0000000000200000 > > >>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > > >>> base=0x0000000000200000 > > >>> (XEN) GDTR: limit=0x00001dd8, > > >>> base=0x0000000000200000 > > >>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > > >>> base=0x0000000000000000 > > >>> (XEN) IDTR: limit=0x00000188, > > >>> base=0x0000000000201df0 > > >>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > > >>> base=0x0000000000201ff2 > > >>> (XEN) Guest PAT = 0x0000000000000000 > > >>> (XEN) TSC Offset = ffffffe4920110b7 > > >>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > > >>> (XEN) Interruptibility=0001 ActivityState=0000 > > >>> (XEN) *** Host State *** > > >>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > > >>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > > >>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > > >>> TRBase=ffff828c802a8b00 > > >>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > > >>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 CR4=00000000000026f0 > > >>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > > >>> (XEN) Host PAT = 0x0000000000000000 > > >>> (XEN) *** Control State *** > > >>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > > >>> (XEN) EntryControls=000011ff ExitControls=0003efff > > >>> (XEN) ExceptionBitmap=00044080 > > >>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > > >>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > > >>> (XEN) reason=80000021 qualification=00000000 > > >>> (XEN) IDTVectoring: info=00000000 errcode=00000000 > > >>> (XEN) TPR Threshold = 0x00 > > >>> (XEN) EPT pointer = 0x0000000000000000 > > >>> (XEN) Virtual processor ID = 0x0000 > > >>> (XEN) ************************************** > > >>> (XEN) domain_crash called from vmx.c:2218 > > >>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > > >>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- > > >>> (XEN) CPU: 1 > > >>> (XEN) RIP: 0060:[<000000000000002a>] > > >>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > > >>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: > 0000000000000000 > > >>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: > 0000000000000000 > > >>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: > 0000000000000000 > > >>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > 0000000000000000 > > >>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > 0000000000000000 > > >>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: > 0000000000000000 > > >>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > > >>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 > > >>> > > >>> Could it be, that the real mode emulation code has a bug? What does > this > > >>> error means? > > >>> > > >>> Tom > > >>> > > >>> 2009/4/22 Keir Fraser > > >>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> > > >>> On 22/04/2009 12:18, "Tom Rotenberg" > > >>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> wrote: > > >>> > > >>>> Keir, > > >>>> > > >>>> I have applied your patch, and it seemed to work. However, the > domain still > > >>>> crashes, and now it looks like it's because of the 'LTR' > instruction. > > >>> > > >>> Try the attached patch. It replaces the one I sent last time, and > emulates > > >>> both LLDT and LTR. > > >>> > > >>> -- Keir > > >>> > > >> > > >> Content-Description: ATT00001.txt > > >>> _______________________________________________ > > >>> Xen-devel mailing list > > >>> Xen-devel@lists.xensource.com > > >>> http://lists.xensource.com/xen-devel > > >> > > >> > > >> -- > > >> Tim Deegan <Tim.Deegan@citrix.com> > > >> Principal Software Engineer, Citrix Systems (R&D) Ltd. > > >> [Company #02300071, SL9 0DZ, UK.] > > > > > > > > > -- > Tim Deegan <Tim.Deegan@citrix.com> > Principal Software Engineer, Citrix Systems (R&D) Ltd. > [Company #02300071, SL9 0DZ, UK.] > [-- Attachment #1.2: Type: text/html, Size: 13006 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 13:52 ` Tom Rotenberg @ 2009-04-22 13:59 ` Keir Fraser 2009-04-22 14:04 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-22 13:59 UTC (permalink / raw) To: Tom Rotenberg, Tim Deegan; +Cc: xen-devel@lists.xensource.com Yes, the safest way to be sure is probably to replace the if() statement in vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with if(0). That is the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can re-build/install Xen and be sure that vm86 accel must be disabled. -- Keir On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and re-check it? > > 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> >> At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: >>> It could be an issue with the vm86 acceleration, possibly. I'm pretty sure >>> the guest would have to IRET from protected mode to enter vm86 mode itself, >>> and we don't emulate that. Tim: what would we need to do to disable the vm86 >>> acceleration for testing purposes? You suggested not setting VM86_TSS param >>> from hvmloader, but I couldn't convince myself what effect that would >>> actually have as the logic in Xen is non-trivial. >> >> Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() will >> always set the tss bit in the bitmap of segments that aren't safe to >> enter VM86 with. >> >> Tim. >> >>> >>> -- Keir >>> >>> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >>> >>>> Tim, >>>> >>>> so what does it mean? could it be that we have a bug in the real mode >>>> emulation, which causes the segment state to be invalid (maybe it's because >>>> of >>>> a bug in the patch that Keir made for me, which emulated the LLDT, and the >>>> LTR >>>> instructions)? >>>> >>>> Keir suggested to trace back where the problem (segment state) occured, and >>>> from there to try and find the bug which caused it. Do u have any better >>>> suggestion for solving this? >>>> >>>> Tom >>>> >>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> >>>>> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: >>>>>> Keir, >>>>>> >>>>>> I have tried your latest patch, and it looks like now it passes the >>>>>> emulation problem. However, now the domain crashes with the following >>>>>> error: >>>>>> >>>>>> (XEN) HVM1: Booting from 0000:7c00 >>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>>>>> state >>>>>> (0). >>>>>> (XEN) ************* VMCS Area ************** >>>>>> (XEN) *** Guest State *** >>>>>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, >>>>>> gh_mask=ffffffffffffffff >>>>>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, >>>>>> gh_mask=ffffffffffffffff >>>>>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 >>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = >>>>>> 0x000000000000002a (0x000000000000002a) >>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = >>>>>> 0x0000000000000400 >>>>> >>>>> Looks like we're trying to VMENTER in virtual 8086 mode but without >>>>> tidying up the segment state. That could either be the guest entering >>>>> virtual 8086 mode itself or Xen entering vitrual 8086 mode to emulate >>>>> real mode, but Xen is always careful to make the segment state agree >>>>> with Intel's rather strict requrements when it does that. >>>>> >>>>> Tim. >>>>> >>>>> >>>>>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 >>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, >>>>>> base=0x0000000000200000 >>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>> base=0x0000000000200000 >>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, >>>>>> base=0x000000000020ba62 >>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>> base=0x0000000000200000 >>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>> base=0x0000000000200000 >>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>> base=0x0000000000200000 >>>>>> (XEN) GDTR: limit=0x00001dd8, >>>>>> base=0x0000000000200000 >>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, >>>>>> base=0x0000000000000000 >>>>>> (XEN) IDTR: limit=0x00000188, >>>>>> base=0x0000000000201df0 >>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, >>>>>> base=0x0000000000201ff2 >>>>>> (XEN) Guest PAT = 0x0000000000000000 >>>>>> (XEN) TSC Offset = ffffffe4920110b7 >>>>>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 >>>>>> (XEN) Interruptibility=0001 ActivityState=0000 >>>>>> (XEN) *** Host State *** >>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 >>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 >>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 >>>>>> TRBase=ffff828c802a8b00 >>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 >>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 CR4=00000000000026f0 >>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 >>>>>> (XEN) Host PAT = 0x0000000000000000 >>>>>> (XEN) *** Control State *** >>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 >>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff >>>>>> (XEN) ExceptionBitmap=00044080 >>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 >>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 >>>>>> (XEN) reason=80000021 qualification=00000000 >>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 >>>>>> (XEN) TPR Threshold = 0x00 >>>>>> (XEN) EPT pointer = 0x0000000000000000 >>>>>> (XEN) Virtual processor ID = 0x0000 >>>>>> (XEN) ************************************** >>>>>> (XEN) domain_crash called from vmx.c:2218 >>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: >>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- >>>>>> (XEN) CPU: 1 >>>>>> (XEN) RIP: 0060:[<000000000000002a>] >>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest >>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: >>>>>> 0000000000000000 >>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: >>>>>> 0000000000000000 >>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: >>>>>> 0000000000000000 >>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: >>>>>> 0000000000000000 >>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: >>>>>> 0000000000000000 >>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: >>>>>> 0000000000000000 >>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 >>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 >>>>>> >>>>>> Could it be, that the real mode emulation code has a bug? What does this >>>>>> error means? >>>>>> >>>>>> Tom >>>>>> >>>>>> 2009/4/22 Keir Fraser >>>>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> >>>>>> On 22/04/2009 12:18, "Tom Rotenberg" >>>>>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> wrote: >>>>>> >>>>>>> Keir, >>>>>>> >>>>>>> I have applied your patch, and it seemed to work. However, the domain >>>>>>> still >>>>>>> crashes, and now it looks like it's because of the 'LTR' instruction. >>>>>> >>>>>> Try the attached patch. It replaces the one I sent last time, and >>>>>> emulates >>>>>> both LLDT and LTR. >>>>>> >>>>>> -- Keir >>>>>> >>>>> >>>>> Content-Description: ATT00001.txt >>>>>> _______________________________________________ >>>>>> Xen-devel mailing list >>>>>> Xen-devel@lists.xensource.com >>>>>> http://lists.xensource.com/xen-devel >>>>> >>>>> >>>>> -- >>>>> Tim Deegan <Tim.Deegan@citrix.com> >>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. >>>>> [Company #02300071, SL9 0DZ, UK.] >>>> >>> >>> >> >> -- >> Tim Deegan <Tim.Deegan@citrix.com> >> Principal Software Engineer, Citrix Systems (R&D) Ltd. >> [Company #02300071, SL9 0DZ, UK.] > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 13:59 ` Keir Fraser @ 2009-04-22 14:04 ` Tom Rotenberg 2009-04-22 14:14 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-22 14:04 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 8919 bytes --] Keir, Just to make sure, i am using the following patch, in order to disable the vm86 acceleration: diff -r cdc044f665dc xen/arch/x86/hvm/vmx/vmx.c --- a/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 11:26:37 2009 +0100 +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 17:03:20 2009 +0300 @@ -829,7 +829,7 @@ if ( seg == x86_seg_tr ) { - if ( v->domain->arch.hvm_domain.params[HVM_PARAM_VM86_TSS] ) + if (0) { sel = 0; attr = vm86_tr_attr; Is this OK? Tom 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > Yes, the safest way to be sure is probably to replace the if() statement in > vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with if(0). That > is > the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can > re-build/install Xen and be sure that vm86 accel must be disabled. > > -- Keir > > On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and re-check > it? > > > > 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >> At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: > >>> It could be an issue with the vm86 acceleration, possibly. I'm pretty > sure > >>> the guest would have to IRET from protected mode to enter vm86 mode > itself, > >>> and we don't emulate that. Tim: what would we need to do to disable the > vm86 > >>> acceleration for testing purposes? You suggested not setting VM86_TSS > param > >>> from hvmloader, but I couldn't convince myself what effect that would > >>> actually have as the logic in Xen is non-trivial. > >> > >> Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() will > >> always set the tss bit in the bitmap of segments that aren't safe to > >> enter VM86 with. > >> > >> Tim. > >> > >>> > >>> -- Keir > >>> > >>> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > >>> > >>>> Tim, > >>>> > >>>> so what does it mean? could it be that we have a bug in the real mode > >>>> emulation, which causes the segment state to be invalid (maybe it's > because > >>>> of > >>>> a bug in the patch that Keir made for me, which emulated the LLDT, and > the > >>>> LTR > >>>> instructions)? > >>>> > >>>> Keir suggested to trace back where the problem (segment state) > occured, and > >>>> from there to try and find the bug which caused it. Do u have any > better > >>>> suggestion for solving this? > >>>> > >>>> Tom > >>>> > >>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >>>>> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: > >>>>>> Keir, > >>>>>> > >>>>>> I have tried your latest patch, and it looks like now it passes the > >>>>>> emulation problem. However, now the domain crashes with the > following > >>>>>> error: > >>>>>> > >>>>>> (XEN) HVM1: Booting from 0000:7c00 > >>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid > guest > >>>>>> state > >>>>>> (0). > >>>>>> (XEN) ************* VMCS Area ************** > >>>>>> (XEN) *** Guest State *** > >>>>>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, > >>>>>> gh_mask=ffffffffffffffff > >>>>>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, > >>>>>> gh_mask=ffffffffffffffff > >>>>>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 > >>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 > >>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 > >>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > >>>>>> 0x000000000000002a (0x000000000000002a) > >>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > >>>>>> 0x0000000000000400 > >>>>> > >>>>> Looks like we're trying to VMENTER in virtual 8086 mode but without > >>>>> tidying up the segment state. That could either be the guest > entering > >>>>> virtual 8086 mode itself or Xen entering vitrual 8086 mode to emulate > >>>>> real mode, but Xen is always careful to make the segment state agree > >>>>> with Intel's rather strict requrements when it does that. > >>>>> > >>>>> Tim. > >>>>> > >>>>> > >>>>>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > >>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > >>>>>> base=0x0000000000200000 > >>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>> base=0x0000000000200000 > >>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > >>>>>> base=0x000000000020ba62 > >>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>> base=0x0000000000200000 > >>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>> base=0x0000000000200000 > >>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>> base=0x0000000000200000 > >>>>>> (XEN) GDTR: limit=0x00001dd8, > >>>>>> base=0x0000000000200000 > >>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > >>>>>> base=0x0000000000000000 > >>>>>> (XEN) IDTR: limit=0x00000188, > >>>>>> base=0x0000000000201df0 > >>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > >>>>>> base=0x0000000000201ff2 > >>>>>> (XEN) Guest PAT = 0x0000000000000000 > >>>>>> (XEN) TSC Offset = ffffffe4920110b7 > >>>>>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > >>>>>> (XEN) Interruptibility=0001 ActivityState=0000 > >>>>>> (XEN) *** Host State *** > >>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > >>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > >>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > >>>>>> TRBase=ffff828c802a8b00 > >>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > >>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 CR4=00000000000026f0 > >>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > >>>>>> (XEN) Host PAT = 0x0000000000000000 > >>>>>> (XEN) *** Control State *** > >>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > >>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff > >>>>>> (XEN) ExceptionBitmap=00044080 > >>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > >>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > >>>>>> (XEN) reason=80000021 qualification=00000000 > >>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 > >>>>>> (XEN) TPR Threshold = 0x00 > >>>>>> (XEN) EPT pointer = 0x0000000000000000 > >>>>>> (XEN) Virtual processor ID = 0x0000 > >>>>>> (XEN) ************************************** > >>>>>> (XEN) domain_crash called from vmx.c:2218 > >>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > >>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- > >>>>>> (XEN) CPU: 1 > >>>>>> (XEN) RIP: 0060:[<000000000000002a>] > >>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > >>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: > >>>>>> 0000000000000000 > >>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: > >>>>>> 0000000000000000 > >>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: > >>>>>> 0000000000000000 > >>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > >>>>>> 0000000000000000 > >>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > >>>>>> 0000000000000000 > >>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: > >>>>>> 0000000000000000 > >>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > >>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: > 0060 > >>>>>> > >>>>>> Could it be, that the real mode emulation code has a bug? What does > this > >>>>>> error means? > >>>>>> > >>>>>> Tom > >>>>>> > >>>>>> 2009/4/22 Keir Fraser > >>>>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> > >>>>>> On 22/04/2009 12:18, "Tom Rotenberg" > >>>>>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> wrote: > >>>>>> > >>>>>>> Keir, > >>>>>>> > >>>>>>> I have applied your patch, and it seemed to work. However, the > domain > >>>>>>> still > >>>>>>> crashes, and now it looks like it's because of the 'LTR' > instruction. > >>>>>> > >>>>>> Try the attached patch. It replaces the one I sent last time, and > >>>>>> emulates > >>>>>> both LLDT and LTR. > >>>>>> > >>>>>> -- Keir > >>>>>> > >>>>> > >>>>> Content-Description: ATT00001.txt > >>>>>> _______________________________________________ > >>>>>> Xen-devel mailing list > >>>>>> Xen-devel@lists.xensource.com > >>>>>> http://lists.xensource.com/xen-devel > >>>>> > >>>>> > >>>>> -- > >>>>> Tim Deegan <Tim.Deegan@citrix.com> > >>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >>>>> [Company #02300071, SL9 0DZ, UK.] > >>>> > >>> > >>> > >> > >> -- > >> Tim Deegan <Tim.Deegan@citrix.com> > >> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >> [Company #02300071, SL9 0DZ, UK.] > > > > > [-- Attachment #1.2: Type: text/html, Size: 13403 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 14:04 ` Tom Rotenberg @ 2009-04-22 14:14 ` Keir Fraser 2009-04-22 14:20 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-22 14:14 UTC (permalink / raw) To: Tom Rotenberg; +Cc: Tim Deegan, xen-devel@lists.xensource.com That should do it. K. On 22/04/2009 15:04, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > Keir, > Just to make sure, i am using the following patch, in order to disable the > vm86 acceleration: > > diff -r cdc044f665dc xen/arch/x86/hvm/vmx/vmx.c > --- a/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 11:26:37 2009 +0100 > +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 17:03:20 2009 +0300 > @@ -829,7 +829,7 @@ > > if ( seg == x86_seg_tr ) > { > - if ( v->domain->arch.hvm_domain.params[HVM_PARAM_VM86_TSS] ) > + if (0) > { > sel = 0; > attr = vm86_tr_attr; > > Is this OK? > > Tom > > 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> >> Yes, the safest way to be sure is probably to replace the if() statement in >> vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with if(0). That is >> the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can >> re-build/install Xen and be sure that vm86 accel must be disabled. >> >> -- Keir >> >> On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >> >>> So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and re-check it? >>> >>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> >>>> At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: >>>>> It could be an issue with the vm86 acceleration, possibly. I'm pretty sure >>>>> the guest would have to IRET from protected mode to enter vm86 mode >>>>> itself, >>>>> and we don't emulate that. Tim: what would we need to do to disable the >>>>> vm86 >>>>> acceleration for testing purposes? You suggested not setting VM86_TSS >>>>> param >>>>> from hvmloader, but I couldn't convince myself what effect that would >>>>> actually have as the logic in Xen is non-trivial. >>>> >>>> Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() will >>>> always set the tss bit in the bitmap of segments that aren't safe to >>>> enter VM86 with. >>>> >>>> Tim. >>>> >>>>> >>>>> -- Keir >>>>> >>>>> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >>>>> >>>>>> Tim, >>>>>> >>>>>> so what does it mean? could it be that we have a bug in the real mode >>>>>> emulation, which causes the segment state to be invalid (maybe it's >>>>>> because >>>>>> of >>>>>> a bug in the patch that Keir made for me, which emulated the LLDT, and >>>>>> the >>>>>> LTR >>>>>> instructions)? >>>>>> >>>>>> Keir suggested to trace back where the problem (segment state) occured, >>>>>> and >>>>>> from there to try and find the bug which caused it. Do u have any better >>>>>> suggestion for solving this? >>>>>> >>>>>> Tom >>>>>> >>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> >>>>>>> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: >>>>>>>> Keir, >>>>>>>> >>>>>>>> I have tried your latest patch, and it looks like now it passes the >>>>>>>> emulation problem. However, now the domain crashes with the following >>>>>>>> error: >>>>>>>> >>>>>>>> (XEN) HVM1: Booting from 0000:7c00 >>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>>>>>>> state >>>>>>>> (0). >>>>>>>> (XEN) ************* VMCS Area ************** >>>>>>>> (XEN) *** Guest State *** >>>>>>>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, >>>>>>>> gh_mask=ffffffffffffffff >>>>>>>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, >>>>>>>> gh_mask=ffffffffffffffff >>>>>>>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 >>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = >>>>>>>> 0x000000000000002a (0x000000000000002a) >>>>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = >>>>>>>> 0x0000000000000400 >>>>>>> >>>>>>> Looks like we're trying to VMENTER in virtual 8086 mode but without >>>>>>> tidying up the segment state. That could either be the guest entering >>>>>>> virtual 8086 mode itself or Xen entering vitrual 8086 mode to emulate >>>>>>> real mode, but Xen is always careful to make the segment state agree >>>>>>> with Intel's rather strict requrements when it does that. >>>>>>> >>>>>>> Tim. >>>>>>> >>>>>>> >>>>>>>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 >>>>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, >>>>>>>> base=0x0000000000200000 >>>>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>> base=0x0000000000200000 >>>>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, >>>>>>>> base=0x000000000020ba62 >>>>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>> base=0x0000000000200000 >>>>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>> base=0x0000000000200000 >>>>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>> base=0x0000000000200000 >>>>>>>> (XEN) GDTR: limit=0x00001dd8, >>>>>>>> base=0x0000000000200000 >>>>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, >>>>>>>> base=0x0000000000000000 >>>>>>>> (XEN) IDTR: limit=0x00000188, >>>>>>>> base=0x0000000000201df0 >>>>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, >>>>>>>> base=0x0000000000201ff2 >>>>>>>> (XEN) Guest PAT = 0x0000000000000000 >>>>>>>> (XEN) TSC Offset = ffffffe4920110b7 >>>>>>>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 >>>>>>>> (XEN) Interruptibility=0001 ActivityState=0000 >>>>>>>> (XEN) *** Host State *** >>>>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 >>>>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 >>>>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 >>>>>>>> TRBase=ffff828c802a8b00 >>>>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 >>>>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 CR4=00000000000026f0 >>>>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 >>>>>>>> (XEN) Host PAT = 0x0000000000000000 >>>>>>>> (XEN) *** Control State *** >>>>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 >>>>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff >>>>>>>> (XEN) ExceptionBitmap=00044080 >>>>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 >>>>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 >>>>>>>> (XEN) reason=80000021 qualification=00000000 >>>>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 >>>>>>>> (XEN) TPR Threshold = 0x00 >>>>>>>> (XEN) EPT pointer = 0x0000000000000000 >>>>>>>> (XEN) Virtual processor ID = 0x0000 >>>>>>>> (XEN) ************************************** >>>>>>>> (XEN) domain_crash called from vmx.c:2218 >>>>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: >>>>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- >>>>>>>> (XEN) CPU: 1 >>>>>>>> (XEN) RIP: 0060:[<000000000000002a>] >>>>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest >>>>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: >>>>>>>> 0000000000000000 >>>>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: >>>>>>>> 0000000000000000 >>>>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: >>>>>>>> 0000000000000000 >>>>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: >>>>>>>> 0000000000000000 >>>>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: >>>>>>>> 0000000000000000 >>>>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: >>>>>>>> 0000000000000000 >>>>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 >>>>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 >>>>>>>> >>>>>>>> Could it be, that the real mode emulation code has a bug? What does >>>>>>>> this >>>>>>>> error means? >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> 2009/4/22 Keir Fraser >>>>>>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> >>>>>>>> On 22/04/2009 12:18, "Tom Rotenberg" >>>>>>>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> wrote: >>>>>>>> >>>>>>>>> Keir, >>>>>>>>> >>>>>>>>> I have applied your patch, and it seemed to work. However, the domain >>>>>>>>> still >>>>>>>>> crashes, and now it looks like it's because of the 'LTR' instruction. >>>>>>>> >>>>>>>> Try the attached patch. It replaces the one I sent last time, and >>>>>>>> emulates >>>>>>>> both LLDT and LTR. >>>>>>>> >>>>>>>> -- Keir >>>>>>>> >>>>>>> >>>>>>> Content-Description: ATT00001.txt >>>>>>>> _______________________________________________ >>>>>>>> Xen-devel mailing list >>>>>>>> Xen-devel@lists.xensource.com >>>>>>>> http://lists.xensource.com/xen-devel >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Tim Deegan <Tim.Deegan@citrix.com> >>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. >>>>>>> [Company #02300071, SL9 0DZ, UK.] >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> Tim Deegan <Tim.Deegan@citrix.com> >>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. >>>> [Company #02300071, SL9 0DZ, UK.] >>> >> >> > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 14:14 ` Keir Fraser @ 2009-04-22 14:20 ` Tom Rotenberg 2009-04-22 14:25 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-22 14:20 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 13340 bytes --] Well, just tried this patch, and it doesn't seem to work. I get the following error: (XEN) HVM1: Booting from 0000:7c00 (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state (0). (XEN) ************* VMCS Area ************** (XEN) *** Guest State *** (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, gh_mask=ffffffffffffffff (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, gh_mask=ffffffffffffffff (XEN) CR3: actual=0x000000000a22fa20, target_count=0 (XEN) target0=0000000000000000, target1=0000000000000000 (XEN) target2=0000000000000000, target3=0000000000000000 (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = 0x000000000000002a (0x000000000000002a) (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = 0x0000000000000400 (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, base=0x0000000000200000 (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, base=0x000000000020ba62 (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 (XEN) GDTR: limit=0x00001dd8, base=0x0000000000200000 (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, base=0x0000000000000000 (XEN) IDTR: limit=0x00000188, base=0x0000000000201df0 (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, base=0x0000000000201ff2 (XEN) Guest PAT = 0x0000000000000000 (XEN) TSC Offset = ffffffe2242f086e (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 (XEN) Interruptibility=0001 ActivityState=0000 (XEN) *** Host State *** (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 (XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff828c802a8b00 (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 (XEN) CR0=0000000080050033 CR3=000000007cfd8000 CR4=00000000000026f0 (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 (XEN) Host PAT = 0x0000000000000000 (XEN) *** Control State *** (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 (XEN) EntryControls=000011ff ExitControls=0003efff (XEN) ExceptionBitmap=00044080 (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 (XEN) reason=80000021 qualification=00000000 (XEN) IDTVectoring: info=00000000 errcode=00000000 (XEN) TPR Threshold = 0x00 (XEN) EPT pointer = 0x0000000000000000 (XEN) Virtual processor ID = 0x0000 (XEN) ************************************** (XEN) domain_crash called from vmx.c:2218 (XEN) Domain 1 (vcpu#0) crashed on cpu#1: (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- (XEN) CPU: 1 (XEN) RIP: 0060:[<000000000000002a>] (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: 0000000000000000 (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: 0000000000000000 (XEN) cr3: 0000000001443000 cr2: 0000000000000000 (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 Any ideas? Tom 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > That should do it. > > K. > > > On 22/04/2009 15:04, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > Keir, > > Just to make sure, i am using the following patch, in order to disable > the > > vm86 acceleration: > > > > diff -r cdc044f665dc xen/arch/x86/hvm/vmx/vmx.c > > --- a/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 11:26:37 2009 +0100 > > +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 17:03:20 2009 +0300 > > @@ -829,7 +829,7 @@ > > > > if ( seg == x86_seg_tr ) > > { > > - if ( v->domain->arch.hvm_domain.params[HVM_PARAM_VM86_TSS] ) > > + if (0) > > { > > sel = 0; > > attr = vm86_tr_attr; > > > > Is this OK? > > > > Tom > > > > 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >> Yes, the safest way to be sure is probably to replace the if() statement > in > >> vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with if(0). > That is > >> the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can > >> re-build/install Xen and be sure that vm86 accel must be disabled. > >> > >> -- Keir > >> > >> On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > >> > >>> So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and re-check > it? > >>> > >>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >>>> At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: > >>>>> It could be an issue with the vm86 acceleration, possibly. I'm pretty > sure > >>>>> the guest would have to IRET from protected mode to enter vm86 mode > >>>>> itself, > >>>>> and we don't emulate that. Tim: what would we need to do to disable > the > >>>>> vm86 > >>>>> acceleration for testing purposes? You suggested not setting VM86_TSS > >>>>> param > >>>>> from hvmloader, but I couldn't convince myself what effect that would > >>>>> actually have as the logic in Xen is non-trivial. > >>>> > >>>> Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() will > >>>> always set the tss bit in the bitmap of segments that aren't safe to > >>>> enter VM86 with. > >>>> > >>>> Tim. > >>>> > >>>>> > >>>>> -- Keir > >>>>> > >>>>> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> > wrote: > >>>>> > >>>>>> Tim, > >>>>>> > >>>>>> so what does it mean? could it be that we have a bug in the real > mode > >>>>>> emulation, which causes the segment state to be invalid (maybe it's > >>>>>> because > >>>>>> of > >>>>>> a bug in the patch that Keir made for me, which emulated the LLDT, > and > >>>>>> the > >>>>>> LTR > >>>>>> instructions)? > >>>>>> > >>>>>> Keir suggested to trace back where the problem (segment state) > occured, > >>>>>> and > >>>>>> from there to try and find the bug which caused it. Do u have any > better > >>>>>> suggestion for solving this? > >>>>>> > >>>>>> Tom > >>>>>> > >>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: > >>>>>>>> Keir, > >>>>>>>> > >>>>>>>> I have tried your latest patch, and it looks like now it passes > the > >>>>>>>> emulation problem. However, now the domain crashes with the > following > >>>>>>>> error: > >>>>>>>> > >>>>>>>> (XEN) HVM1: Booting from 0000:7c00 > >>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid > guest > >>>>>>>> state > >>>>>>>> (0). > >>>>>>>> (XEN) ************* VMCS Area ************** > >>>>>>>> (XEN) *** Guest State *** > >>>>>>>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, > >>>>>>>> gh_mask=ffffffffffffffff > >>>>>>>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, > >>>>>>>> gh_mask=ffffffffffffffff > >>>>>>>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 > >>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 > >>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 > >>>>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > >>>>>>>> 0x000000000000002a (0x000000000000002a) > >>>>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > >>>>>>>> 0x0000000000000400 > >>>>>>> > >>>>>>> Looks like we're trying to VMENTER in virtual 8086 mode but without > >>>>>>> tidying up the segment state. That could either be the guest > entering > >>>>>>> virtual 8086 mode itself or Xen entering vitrual 8086 mode to > emulate > >>>>>>> real mode, but Xen is always careful to make the segment state > agree > >>>>>>> with Intel's rather strict requrements when it does that. > >>>>>>> > >>>>>>> Tim. > >>>>>>> > >>>>>>> > >>>>>>>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > >>>>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > >>>>>>>> base=0x0000000000200000 > >>>>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>> base=0x0000000000200000 > >>>>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > >>>>>>>> base=0x000000000020ba62 > >>>>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>> base=0x0000000000200000 > >>>>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>> base=0x0000000000200000 > >>>>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>> base=0x0000000000200000 > >>>>>>>> (XEN) GDTR: limit=0x00001dd8, > >>>>>>>> base=0x0000000000200000 > >>>>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > >>>>>>>> base=0x0000000000000000 > >>>>>>>> (XEN) IDTR: limit=0x00000188, > >>>>>>>> base=0x0000000000201df0 > >>>>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > >>>>>>>> base=0x0000000000201ff2 > >>>>>>>> (XEN) Guest PAT = 0x0000000000000000 > >>>>>>>> (XEN) TSC Offset = ffffffe4920110b7 > >>>>>>>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > >>>>>>>> (XEN) Interruptibility=0001 ActivityState=0000 > >>>>>>>> (XEN) *** Host State *** > >>>>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > >>>>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > >>>>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > >>>>>>>> TRBase=ffff828c802a8b00 > >>>>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > >>>>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 > CR4=00000000000026f0 > >>>>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > >>>>>>>> (XEN) Host PAT = 0x0000000000000000 > >>>>>>>> (XEN) *** Control State *** > >>>>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > >>>>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff > >>>>>>>> (XEN) ExceptionBitmap=00044080 > >>>>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > >>>>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > >>>>>>>> (XEN) reason=80000021 qualification=00000000 > >>>>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 > >>>>>>>> (XEN) TPR Threshold = 0x00 > >>>>>>>> (XEN) EPT pointer = 0x0000000000000000 > >>>>>>>> (XEN) Virtual processor ID = 0x0000 > >>>>>>>> (XEN) ************************************** > >>>>>>>> (XEN) domain_crash called from vmx.c:2218 > >>>>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > >>>>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- > >>>>>>>> (XEN) CPU: 1 > >>>>>>>> (XEN) RIP: 0060:[<000000000000002a>] > >>>>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > >>>>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: > >>>>>>>> 0000000000000000 > >>>>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: > >>>>>>>> 0000000000000000 > >>>>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: > >>>>>>>> 0000000000000000 > >>>>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > >>>>>>>> 0000000000000000 > >>>>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > >>>>>>>> 0000000000000000 > >>>>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: > >>>>>>>> 0000000000000000 > >>>>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > >>>>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: > 0060 > >>>>>>>> > >>>>>>>> Could it be, that the real mode emulation code has a bug? What > does > >>>>>>>> this > >>>>>>>> error means? > >>>>>>>> > >>>>>>>> Tom > >>>>>>>> > >>>>>>>> 2009/4/22 Keir Fraser > >>>>>>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> > >>>>>>>> On 22/04/2009 12:18, "Tom Rotenberg" > >>>>>>>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> wrote: > >>>>>>>> > >>>>>>>>> Keir, > >>>>>>>>> > >>>>>>>>> I have applied your patch, and it seemed to work. However, the > domain > >>>>>>>>> still > >>>>>>>>> crashes, and now it looks like it's because of the 'LTR' > instruction. > >>>>>>>> > >>>>>>>> Try the attached patch. It replaces the one I sent last time, and > >>>>>>>> emulates > >>>>>>>> both LLDT and LTR. > >>>>>>>> > >>>>>>>> -- Keir > >>>>>>>> > >>>>>>> > >>>>>>> Content-Description: ATT00001.txt > >>>>>>>> _______________________________________________ > >>>>>>>> Xen-devel mailing list > >>>>>>>> Xen-devel@lists.xensource.com > >>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >>>>>>> [Company #02300071, SL9 0DZ, UK.] > >>>>>> > >>>>> > >>>>> > >>>> > >>>> -- > >>>> Tim Deegan <Tim.Deegan@citrix.com> > >>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >>>> [Company #02300071, SL9 0DZ, UK.] > >>> > >> > >> > > > > > [-- Attachment #1.2: Type: text/html, Size: 19583 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 14:20 ` Tom Rotenberg @ 2009-04-22 14:25 ` Keir Fraser 2009-04-22 14:40 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-22 14:25 UTC (permalink / raw) To: Tom Rotenberg; +Cc: Tim Deegan, xen-devel@lists.xensource.com Then it probably is a mis-emulation somewhere down the line. Unfortunately that could be hard to track down, even if we had PointSec software to hand, which we do not. -- Keir On 22/04/2009 15:20, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > Well, just tried this patch, and it doesn't seem to work. > I get the following error: > > (XEN) HVM1: Booting from 0000:7c00 > (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state > (0). > (XEN) ************* VMCS Area ************** > (XEN) *** Guest State *** > (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, > gh_mask=ffffffffffffffff > (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, > gh_mask=ffffffffffffffff > (XEN) CR3: actual=0x000000000a22fa20, target_count=0 > (XEN) target0=0000000000000000, target1=0000000000000000 > (XEN) target2=0000000000000000, target3=0000000000000000 > (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = 0x000000000000002a > (0x000000000000002a) > (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = 0x0000000000000400 > (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, base=0x0000000000200000 > (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 > (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, base=0x000000000020ba62 > (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 > (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 > (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, base=0x0000000000200000 > (XEN) GDTR: limit=0x00001dd8, > base=0x0000000000200000 > (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > base=0x0000000000000000 > (XEN) IDTR: limit=0x00000188, > base=0x0000000000201df0 > (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, base=0x0000000000201ff2 > (XEN) Guest PAT = 0x0000000000000000 > (XEN) TSC Offset = ffffffe2242f086e > (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > (XEN) Interruptibility=0001 ActivityState=0000 > (XEN) *** Host State *** > (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > (XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff828c802a8b00 > (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > (XEN) CR0=0000000080050033 CR3=000000007cfd8000 CR4=00000000000026f0 > (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > (XEN) Host PAT = 0x0000000000000000 > (XEN) *** Control State *** > (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > (XEN) EntryControls=000011ff ExitControls=0003efff > (XEN) ExceptionBitmap=00044080 > (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > (XEN) reason=80000021 qualification=00000000 > (XEN) IDTVectoring: info=00000000 errcode=00000000 > (XEN) TPR Threshold = 0x00 > (XEN) EPT pointer = 0x0000000000000000 > (XEN) Virtual processor ID = 0x0000 > (XEN) ************************************** > (XEN) domain_crash called from vmx.c:2218 > (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- > (XEN) CPU: 1 > (XEN) RIP: 0060:[<000000000000002a>] > (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: 0000000000000000 > (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: 0000000000000000 > (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: 0000000000000000 > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 > (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: 0000000000000000 > (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 > > > Any ideas? > > Tom > > > 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> >> That should do it. >> >> K. >> >> >> On 22/04/2009 15:04, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >> >>> Keir, >>> Just to make sure, i am using the following patch, in order to disable the >>> vm86 acceleration: >>> >>> diff -r cdc044f665dc xen/arch/x86/hvm/vmx/vmx.c >>> --- a/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 11:26:37 2009 +0100 >>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 17:03:20 2009 +0300 >>> @@ -829,7 +829,7 @@ >>> >>> if ( seg == x86_seg_tr ) >>> { >>> - if ( v->domain->arch.hvm_domain.params[HVM_PARAM_VM86_TSS] ) >>> + if (0) >>> { >>> sel = 0; >>> attr = vm86_tr_attr; >>> >>> Is this OK? >>> >>> Tom >>> >>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> >>>> Yes, the safest way to be sure is probably to replace the if() statement in >>>> vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with if(0). That >>>> is >>>> the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can >>>> re-build/install Xen and be sure that vm86 accel must be disabled. >>>> >>>> -- Keir >>>> >>>> On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >>>> >>>>> So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and re-check >>>>> it? >>>>> >>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> >>>>>> At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: >>>>>>> It could be an issue with the vm86 acceleration, possibly. I'm pretty >>>>>>> sure >>>>>>> the guest would have to IRET from protected mode to enter vm86 mode >>>>>>> itself, >>>>>>> and we don't emulate that. Tim: what would we need to do to disable the >>>>>>> vm86 >>>>>>> acceleration for testing purposes? You suggested not setting VM86_TSS >>>>>>> param >>>>>>> from hvmloader, but I couldn't convince myself what effect that would >>>>>>> actually have as the logic in Xen is non-trivial. >>>>>> >>>>>> Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() will >>>>>> always set the tss bit in the bitmap of segments that aren't safe to >>>>>> enter VM86 with. >>>>>> >>>>>> Tim. >>>>>> >>>>>>> >>>>>>> -- Keir >>>>>>> >>>>>>> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >>>>>>> >>>>>>>> Tim, >>>>>>>> >>>>>>>> so what does it mean? could it be that we have a bug in the real mode >>>>>>>> emulation, which causes the segment state to be invalid (maybe it's >>>>>>>> because >>>>>>>> of >>>>>>>> a bug in the patch that Keir made for me, which emulated the LLDT, and >>>>>>>> the >>>>>>>> LTR >>>>>>>> instructions)? >>>>>>>> >>>>>>>> Keir suggested to trace back where the problem (segment state) occured, >>>>>>>> and >>>>>>>> from there to try and find the bug which caused it. Do u have any >>>>>>>> better >>>>>>>> suggestion for solving this? >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> >>>>>>>>> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: >>>>>>>>>> Keir, >>>>>>>>>> >>>>>>>>>> I have tried your latest patch, and it looks like now it passes the >>>>>>>>>> emulation problem. However, now the domain crashes with the >>>>>>>>>> following >>>>>>>>>> error: >>>>>>>>>> >>>>>>>>>> (XEN) HVM1: Booting from 0000:7c00 >>>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid >>>>>>>>>> guest >>>>>>>>>> state >>>>>>>>>> (0). >>>>>>>>>> (XEN) ************* VMCS Area ************** >>>>>>>>>> (XEN) *** Guest State *** >>>>>>>>>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, >>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, >>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 >>>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = >>>>>>>>>> 0x000000000000002a (0x000000000000002a) >>>>>>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = >>>>>>>>>> 0x0000000000000400 >>>>>>>>> >>>>>>>>> Looks like we're trying to VMENTER in virtual 8086 mode but without >>>>>>>>> tidying up the segment state. That could either be the guest entering >>>>>>>>> virtual 8086 mode itself or Xen entering vitrual 8086 mode to emulate >>>>>>>>> real mode, but Xen is always careful to make the segment state agree >>>>>>>>> with Intel's rather strict requrements when it does that. >>>>>>>>> >>>>>>>>> Tim. >>>>>>>>> >>>>>>>>> >>>>>>>>>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 >>>>>>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, >>>>>>>>>> base=0x0000000000200000 >>>>>>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>>>> base=0x0000000000200000 >>>>>>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, >>>>>>>>>> base=0x000000000020ba62 >>>>>>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>>>> base=0x0000000000200000 >>>>>>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>>>> base=0x0000000000200000 >>>>>>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>>>> base=0x0000000000200000 >>>>>>>>>> (XEN) GDTR: limit=0x00001dd8, >>>>>>>>>> base=0x0000000000200000 >>>>>>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, >>>>>>>>>> base=0x0000000000000000 >>>>>>>>>> (XEN) IDTR: limit=0x00000188, >>>>>>>>>> base=0x0000000000201df0 >>>>>>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, >>>>>>>>>> base=0x0000000000201ff2 >>>>>>>>>> (XEN) Guest PAT = 0x0000000000000000 >>>>>>>>>> (XEN) TSC Offset = ffffffe4920110b7 >>>>>>>>>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 >>>>>>>>>> (XEN) Interruptibility=0001 ActivityState=0000 >>>>>>>>>> (XEN) *** Host State *** >>>>>>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 >>>>>>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 >>>>>>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 >>>>>>>>>> TRBase=ffff828c802a8b00 >>>>>>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 >>>>>>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 CR4=00000000000026f0 >>>>>>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 >>>>>>>>>> (XEN) Host PAT = 0x0000000000000000 >>>>>>>>>> (XEN) *** Control State *** >>>>>>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 >>>>>>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff >>>>>>>>>> (XEN) ExceptionBitmap=00044080 >>>>>>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 >>>>>>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 >>>>>>>>>> (XEN) reason=80000021 qualification=00000000 >>>>>>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 >>>>>>>>>> (XEN) TPR Threshold = 0x00 >>>>>>>>>> (XEN) EPT pointer = 0x0000000000000000 >>>>>>>>>> (XEN) Virtual processor ID = 0x0000 >>>>>>>>>> (XEN) ************************************** >>>>>>>>>> (XEN) domain_crash called from vmx.c:2218 >>>>>>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: >>>>>>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- >>>>>>>>>> (XEN) CPU: 1 >>>>>>>>>> (XEN) RIP: 0060:[<000000000000002a>] >>>>>>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest >>>>>>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: >>>>>>>>>> 0000000000000000 >>>>>>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: >>>>>>>>>> 0000000000000000 >>>>>>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: >>>>>>>>>> 0000000000000000 >>>>>>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: >>>>>>>>>> 0000000000000000 >>>>>>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: >>>>>>>>>> 0000000000000000 >>>>>>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: >>>>>>>>>> 0000000000000000 >>>>>>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 >>>>>>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 >>>>>>>>>> >>>>>>>>>> Could it be, that the real mode emulation code has a bug? What does >>>>>>>>>> this >>>>>>>>>> error means? >>>>>>>>>> >>>>>>>>>> Tom >>>>>>>>>> >>>>>>>>>> 2009/4/22 Keir Fraser >>>>>>>>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> >>>>>>>>>> On 22/04/2009 12:18, "Tom Rotenberg" >>>>>>>>>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> wrote: >>>>>>>>>> >>>>>>>>>>> Keir, >>>>>>>>>>> >>>>>>>>>>> I have applied your patch, and it seemed to work. However, the >>>>>>>>>>> domain >>>>>>>>>>> still >>>>>>>>>>> crashes, and now it looks like it's because of the 'LTR' >>>>>>>>>>> instruction. >>>>>>>>>> >>>>>>>>>> Try the attached patch. It replaces the one I sent last time, and >>>>>>>>>> emulates >>>>>>>>>> both LLDT and LTR. >>>>>>>>>> >>>>>>>>>> -- Keir >>>>>>>>>> >>>>>>>>> >>>>>>>>> Content-Description: ATT00001.txt >>>>>>>>>> _______________________________________________ >>>>>>>>>> Xen-devel mailing list >>>>>>>>>> Xen-devel@lists.xensource.com >>>>>>>>>> http://lists.xensource.com/xen-devel >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Tim Deegan <Tim.Deegan@citrix.com> >>>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. >>>>>>>>> [Company #02300071, SL9 0DZ, UK.] >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Tim Deegan <Tim.Deegan@citrix.com> >>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. >>>>>> [Company #02300071, SL9 0DZ, UK.] >>>>> >>>> >>>> >>> >> >> > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 14:25 ` Keir Fraser @ 2009-04-22 14:40 ` Tom Rotenberg 2009-04-22 14:48 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-22 14:40 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 14938 bytes --] So, do u have any suggestion for me, on how to advance with this issue? should i debug the real mode emulation myself in order to track it down? will u be able top assist me in any way with this issue? BTW - what is exactly the problem which causes this exception from the CPU? Tim mentioned something about segment state - can u please elaborate on this issue? Tom 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > Then it probably is a mis-emulation somewhere down the line. Unfortunately > that could be hard to track down, even if we had PointSec software to hand, > which we do not. > > -- Keir > > On 22/04/2009 15:20, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > Well, just tried this patch, and it doesn't seem to work. > > I get the following error: > > > > (XEN) HVM1: Booting from 0000:7c00 > > (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest > state > > (0). > > (XEN) ************* VMCS Area ************** > > (XEN) *** Guest State *** > > (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, > > gh_mask=ffffffffffffffff > > (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, > > gh_mask=ffffffffffffffff > > (XEN) CR3: actual=0x000000000a22fa20, target_count=0 > > (XEN) target0=0000000000000000, target1=0000000000000000 > > (XEN) target2=0000000000000000, target3=0000000000000000 > > (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > 0x000000000000002a > > (0x000000000000002a) > > (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > 0x0000000000000400 > > (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > > (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > base=0x0000000000200000 > > (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > base=0x0000000000200000 > > (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > base=0x000000000020ba62 > > (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > base=0x0000000000200000 > > (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > base=0x0000000000200000 > > (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > base=0x0000000000200000 > > (XEN) GDTR: limit=0x00001dd8, > > base=0x0000000000200000 > > (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > > base=0x0000000000000000 > > (XEN) IDTR: limit=0x00000188, > > base=0x0000000000201df0 > > (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > base=0x0000000000201ff2 > > (XEN) Guest PAT = 0x0000000000000000 > > (XEN) TSC Offset = ffffffe2242f086e > > (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > > (XEN) Interruptibility=0001 ActivityState=0000 > > (XEN) *** Host State *** > > (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > > (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > > (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > TRBase=ffff828c802a8b00 > > (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > > (XEN) CR0=0000000080050033 CR3=000000007cfd8000 CR4=00000000000026f0 > > (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > > (XEN) Host PAT = 0x0000000000000000 > > (XEN) *** Control State *** > > (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > > (XEN) EntryControls=000011ff ExitControls=0003efff > > (XEN) ExceptionBitmap=00044080 > > (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > > (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > > (XEN) reason=80000021 qualification=00000000 > > (XEN) IDTVectoring: info=00000000 errcode=00000000 > > (XEN) TPR Threshold = 0x00 > > (XEN) EPT pointer = 0x0000000000000000 > > (XEN) Virtual processor ID = 0x0000 > > (XEN) ************************************** > > (XEN) domain_crash called from vmx.c:2218 > > (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > > (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- > > (XEN) CPU: 1 > > (XEN) RIP: 0060:[<000000000000002a>] > > (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > > (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: > 0000000000000000 > > (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: > 0000000000000000 > > (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: > 0000000000000000 > > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > 0000000000000000 > > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > 0000000000000000 > > (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: > 0000000000000000 > > (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > > (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 > > > > > > Any ideas? > > > > Tom > > > > > > 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >> That should do it. > >> > >> K. > >> > >> > >> On 22/04/2009 15:04, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > >> > >>> Keir, > >>> Just to make sure, i am using the following patch, in order to disable > the > >>> vm86 acceleration: > >>> > >>> diff -r cdc044f665dc xen/arch/x86/hvm/vmx/vmx.c > >>> --- a/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 11:26:37 2009 +0100 > >>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 17:03:20 2009 +0300 > >>> @@ -829,7 +829,7 @@ > >>> > >>> if ( seg == x86_seg_tr ) > >>> { > >>> - if ( v->domain->arch.hvm_domain.params[HVM_PARAM_VM86_TSS] > ) > >>> + if (0) > >>> { > >>> sel = 0; > >>> attr = vm86_tr_attr; > >>> > >>> Is this OK? > >>> > >>> Tom > >>> > >>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >>>> Yes, the safest way to be sure is probably to replace the if() > statement in > >>>> vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with if(0). > That > >>>> is > >>>> the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can > >>>> re-build/install Xen and be sure that vm86 accel must be disabled. > >>>> > >>>> -- Keir > >>>> > >>>> On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > >>>> > >>>>> So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and > re-check > >>>>> it? > >>>>> > >>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >>>>>> At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: > >>>>>>> It could be an issue with the vm86 acceleration, possibly. I'm > pretty > >>>>>>> sure > >>>>>>> the guest would have to IRET from protected mode to enter vm86 mode > >>>>>>> itself, > >>>>>>> and we don't emulate that. Tim: what would we need to do to disable > the > >>>>>>> vm86 > >>>>>>> acceleration for testing purposes? You suggested not setting > VM86_TSS > >>>>>>> param > >>>>>>> from hvmloader, but I couldn't convince myself what effect that > would > >>>>>>> actually have as the logic in Xen is non-trivial. > >>>>>> > >>>>>> Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() will > >>>>>> always set the tss bit in the bitmap of segments that aren't safe to > >>>>>> enter VM86 with. > >>>>>> > >>>>>> Tim. > >>>>>> > >>>>>>> > >>>>>>> -- Keir > >>>>>>> > >>>>>>> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> > wrote: > >>>>>>> > >>>>>>>> Tim, > >>>>>>>> > >>>>>>>> so what does it mean? could it be that we have a bug in the real > mode > >>>>>>>> emulation, which causes the segment state to be invalid (maybe > it's > >>>>>>>> because > >>>>>>>> of > >>>>>>>> a bug in the patch that Keir made for me, which emulated the LLDT, > and > >>>>>>>> the > >>>>>>>> LTR > >>>>>>>> instructions)? > >>>>>>>> > >>>>>>>> Keir suggested to trace back where the problem (segment state) > occured, > >>>>>>>> and > >>>>>>>> from there to try and find the bug which caused it. Do u have any > >>>>>>>> better > >>>>>>>> suggestion for solving this? > >>>>>>>> > >>>>>>>> Tom > >>>>>>>> > >>>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>>> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: > >>>>>>>>>> Keir, > >>>>>>>>>> > >>>>>>>>>> I have tried your latest patch, and it looks like now it passes > the > >>>>>>>>>> emulation problem. However, now the domain crashes with the > >>>>>>>>>> following > >>>>>>>>>> error: > >>>>>>>>>> > >>>>>>>>>> (XEN) HVM1: Booting from 0000:7c00 > >>>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid > >>>>>>>>>> guest > >>>>>>>>>> state > >>>>>>>>>> (0). > >>>>>>>>>> (XEN) ************* VMCS Area ************** > >>>>>>>>>> (XEN) *** Guest State *** > >>>>>>>>>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, > >>>>>>>>>> gh_mask=ffffffffffffffff > >>>>>>>>>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, > >>>>>>>>>> gh_mask=ffffffffffffffff > >>>>>>>>>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 > >>>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 > >>>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 > >>>>>>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > >>>>>>>>>> 0x000000000000002a (0x000000000000002a) > >>>>>>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > >>>>>>>>>> 0x0000000000000400 > >>>>>>>>> > >>>>>>>>> Looks like we're trying to VMENTER in virtual 8086 mode but > without > >>>>>>>>> tidying up the segment state. That could either be the guest > entering > >>>>>>>>> virtual 8086 mode itself or Xen entering vitrual 8086 mode to > emulate > >>>>>>>>> real mode, but Xen is always careful to make the segment state > agree > >>>>>>>>> with Intel's rather strict requrements when it does that. > >>>>>>>>> > >>>>>>>>> Tim. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > >>>>>>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > >>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > >>>>>>>>>> base=0x000000000020ba62 > >>>>>>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>> (XEN) GDTR: limit=0x00001dd8, > >>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > >>>>>>>>>> base=0x0000000000000000 > >>>>>>>>>> (XEN) IDTR: limit=0x00000188, > >>>>>>>>>> base=0x0000000000201df0 > >>>>>>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > >>>>>>>>>> base=0x0000000000201ff2 > >>>>>>>>>> (XEN) Guest PAT = 0x0000000000000000 > >>>>>>>>>> (XEN) TSC Offset = ffffffe4920110b7 > >>>>>>>>>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > >>>>>>>>>> (XEN) Interruptibility=0001 ActivityState=0000 > >>>>>>>>>> (XEN) *** Host State *** > >>>>>>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > >>>>>>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > >>>>>>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > >>>>>>>>>> TRBase=ffff828c802a8b00 > >>>>>>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > >>>>>>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 > CR4=00000000000026f0 > >>>>>>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > >>>>>>>>>> (XEN) Host PAT = 0x0000000000000000 > >>>>>>>>>> (XEN) *** Control State *** > >>>>>>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > >>>>>>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff > >>>>>>>>>> (XEN) ExceptionBitmap=00044080 > >>>>>>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > >>>>>>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > >>>>>>>>>> (XEN) reason=80000021 qualification=00000000 > >>>>>>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 > >>>>>>>>>> (XEN) TPR Threshold = 0x00 > >>>>>>>>>> (XEN) EPT pointer = 0x0000000000000000 > >>>>>>>>>> (XEN) Virtual processor ID = 0x0000 > >>>>>>>>>> (XEN) ************************************** > >>>>>>>>>> (XEN) domain_crash called from vmx.c:2218 > >>>>>>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > >>>>>>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted > ]---- > >>>>>>>>>> (XEN) CPU: 1 > >>>>>>>>>> (XEN) RIP: 0060:[<000000000000002a>] > >>>>>>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > >>>>>>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: > >>>>>>>>>> 0000000000000000 > >>>>>>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: > >>>>>>>>>> 0000000000000000 > >>>>>>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: > >>>>>>>>>> 0000000000000000 > >>>>>>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > >>>>>>>>>> 0000000000000000 > >>>>>>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > >>>>>>>>>> 0000000000000000 > >>>>>>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: > >>>>>>>>>> 0000000000000000 > >>>>>>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > >>>>>>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: > 0060 > >>>>>>>>>> > >>>>>>>>>> Could it be, that the real mode emulation code has a bug? What > does > >>>>>>>>>> this > >>>>>>>>>> error means? > >>>>>>>>>> > >>>>>>>>>> Tom > >>>>>>>>>> > >>>>>>>>>> 2009/4/22 Keir Fraser > >>>>>>>>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> > >>>>>>>>>> On 22/04/2009 12:18, "Tom Rotenberg" > >>>>>>>>>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> > wrote: > >>>>>>>>>> > >>>>>>>>>>> Keir, > >>>>>>>>>>> > >>>>>>>>>>> I have applied your patch, and it seemed to work. However, the > >>>>>>>>>>> domain > >>>>>>>>>>> still > >>>>>>>>>>> crashes, and now it looks like it's because of the 'LTR' > >>>>>>>>>>> instruction. > >>>>>>>>>> > >>>>>>>>>> Try the attached patch. It replaces the one I sent last time, > and > >>>>>>>>>> emulates > >>>>>>>>>> both LLDT and LTR. > >>>>>>>>>> > >>>>>>>>>> -- Keir > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Content-Description: ATT00001.txt > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Xen-devel mailing list > >>>>>>>>>> Xen-devel@lists.xensource.com > >>>>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >>>>>>>>> [Company #02300071, SL9 0DZ, UK.] > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> -- > >>>>>> Tim Deegan <Tim.Deegan@citrix.com> > >>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >>>>>> [Company #02300071, SL9 0DZ, UK.] > >>>>> > >>>> > >>>> > >>> > >> > >> > > > > > [-- Attachment #1.2: Type: text/html, Size: 23151 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 14:40 ` Tom Rotenberg @ 2009-04-22 14:48 ` Keir Fraser 2009-04-22 14:53 ` Tom Rotenberg 2009-04-23 9:56 ` Tom Rotenberg 0 siblings, 2 replies; 43+ messages in thread From: Keir Fraser @ 2009-04-22 14:48 UTC (permalink / raw) To: Tom Rotenberg; +Cc: Tim Deegan, xen-devel@lists.xensource.com On 22/04/2009 15:40, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > So, do u have any suggestion for me, on how to advance with this issue? should > i debug the real mode emulation myself in order to track it down? will u be > able top assist me in any way with this issue? If specific questions arise then certainly yes. > BTW - what is exactly the problem which causes this exception from the CPU? > Tim mentioned something about segment state - can u please elaborate on this > issue? Bit 17 in EFLAGS is set, meaning the guest is in vm86 mode. In this mode, on vmentry, the processor applies specific checks to guest segment register state. These are listed in SDM Vol 3B, but they include checking that segment selector equals segment base address shifted right four bit positions, for example. Clearly the segment state in the dump you emailed is not valid for vm86 mode. Quite possibly PointSec doesn't expect to be in vm86 mode at all, and something may have gone wrong to set that bit in EFLAGS. But it's hard to say at arm's length. -- Keir > Tom > > 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> >> Then it probably is a mis-emulation somewhere down the line. Unfortunately >> that could be hard to track down, even if we had PointSec software to hand, >> which we do not. >> >> -- Keir >> >> On 22/04/2009 15:20, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >> >>> Well, just tried this patch, and it doesn't seem to work. >>> I get the following error: >>> >>> (XEN) HVM1: Booting from 0000:7c00 >>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state >>> (0). >>> (XEN) ************* VMCS Area ************** >>> (XEN) *** Guest State *** >>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, >>> gh_mask=ffffffffffffffff >>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, >>> gh_mask=ffffffffffffffff >>> (XEN) CR3: actual=0x000000000a22fa20, target_count=0 >>> (XEN) target0=0000000000000000, target1=0000000000000000 >>> (XEN) target2=0000000000000000, target3=0000000000000000 >>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = >>> 0x000000000000002a >>> (0x000000000000002a) >>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = >>> 0x0000000000000400 >>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 >>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, >>> base=0x0000000000200000 >>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>> base=0x0000000000200000 >>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, >>> base=0x000000000020ba62 >>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>> base=0x0000000000200000 >>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>> base=0x0000000000200000 >>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>> base=0x0000000000200000 >>> (XEN) GDTR: limit=0x00001dd8, >>> base=0x0000000000200000 >>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, >>> base=0x0000000000000000 >>> (XEN) IDTR: limit=0x00000188, >>> base=0x0000000000201df0 >>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, >>> base=0x0000000000201ff2 >>> (XEN) Guest PAT = 0x0000000000000000 >>> (XEN) TSC Offset = ffffffe2242f086e >>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 >>> (XEN) Interruptibility=0001 ActivityState=0000 >>> (XEN) *** Host State *** >>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 >>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 >>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 >>> TRBase=ffff828c802a8b00 >>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 >>> (XEN) CR0=0000000080050033 CR3=000000007cfd8000 CR4=00000000000026f0 >>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 >>> (XEN) Host PAT = 0x0000000000000000 >>> (XEN) *** Control State *** >>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 >>> (XEN) EntryControls=000011ff ExitControls=0003efff >>> (XEN) ExceptionBitmap=00044080 >>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 >>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 >>> (XEN) reason=80000021 qualification=00000000 >>> (XEN) IDTVectoring: info=00000000 errcode=00000000 >>> (XEN) TPR Threshold = 0x00 >>> (XEN) EPT pointer = 0x0000000000000000 >>> (XEN) Virtual processor ID = 0x0000 >>> (XEN) ************************************** >>> (XEN) domain_crash called from vmx.c:2218 >>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: >>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- >>> (XEN) CPU: 1 >>> (XEN) RIP: 0060:[<000000000000002a>] >>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest >>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: 0000000000000000 >>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: 0000000000000000 >>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: 0000000000000000 >>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 >>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 >>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: 0000000000000000 >>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 >>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 >>> >>> >>> Any ideas? >>> >>> Tom >>> >>> >>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> >>>> That should do it. >>>> >>>> K. >>>> >>>> >>>> On 22/04/2009 15:04, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >>>> >>>>> Keir, >>>>> Just to make sure, i am using the following patch, in order to disable the >>>>> vm86 acceleration: >>>>> >>>>> diff -r cdc044f665dc xen/arch/x86/hvm/vmx/vmx.c >>>>> --- a/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 11:26:37 2009 +0100 >>>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 17:03:20 2009 +0300 >>>>> @@ -829,7 +829,7 @@ >>>>> >>>>> if ( seg == x86_seg_tr ) >>>>> { >>>>> - if ( v->domain->arch.hvm_domain.params[HVM_PARAM_VM86_TSS] ) >>>>> + if (0) >>>>> { >>>>> sel = 0; >>>>> attr = vm86_tr_attr; >>>>> >>>>> Is this OK? >>>>> >>>>> Tom >>>>> >>>>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> >>>>>> Yes, the safest way to be sure is probably to replace the if() statement >>>>>> in >>>>>> vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with if(0). That >>>>>> is >>>>>> the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can >>>>>> re-build/install Xen and be sure that vm86 accel must be disabled. >>>>>> >>>>>> -- Keir >>>>>> >>>>>> On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >>>>>> >>>>>>> So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and re-check >>>>>>> it? >>>>>>> >>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> >>>>>>>> At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: >>>>>>>>> It could be an issue with the vm86 acceleration, possibly. I'm pretty >>>>>>>>> sure >>>>>>>>> the guest would have to IRET from protected mode to enter vm86 mode >>>>>>>>> itself, >>>>>>>>> and we don't emulate that. Tim: what would we need to do to disable >>>>>>>>> the >>>>>>>>> vm86 >>>>>>>>> acceleration for testing purposes? You suggested not setting VM86_TSS >>>>>>>>> param >>>>>>>>> from hvmloader, but I couldn't convince myself what effect that would >>>>>>>>> actually have as the logic in Xen is non-trivial. >>>>>>>> >>>>>>>> Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() will >>>>>>>> always set the tss bit in the bitmap of segments that aren't safe to >>>>>>>> enter VM86 with. >>>>>>>> >>>>>>>> Tim. >>>>>>>> >>>>>>>>> >>>>>>>>> -- Keir >>>>>>>>> >>>>>>>>> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Tim, >>>>>>>>>> >>>>>>>>>> so what does it mean? could it be that we have a bug in the real mode >>>>>>>>>> emulation, which causes the segment state to be invalid (maybe it's >>>>>>>>>> because >>>>>>>>>> of >>>>>>>>>> a bug in the patch that Keir made for me, which emulated the LLDT, >>>>>>>>>> and >>>>>>>>>> the >>>>>>>>>> LTR >>>>>>>>>> instructions)? >>>>>>>>>> >>>>>>>>>> Keir suggested to trace back where the problem (segment state) >>>>>>>>>> occured, >>>>>>>>>> and >>>>>>>>>> from there to try and find the bug which caused it. Do u have any >>>>>>>>>> better >>>>>>>>>> suggestion for solving this? >>>>>>>>>> >>>>>>>>>> Tom >>>>>>>>>> >>>>>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> >>>>>>>>>>> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: >>>>>>>>>>>> Keir, >>>>>>>>>>>> >>>>>>>>>>>> I have tried your latest patch, and it looks like now it passes the >>>>>>>>>>>> emulation problem. However, now the domain crashes with the >>>>>>>>>>>> following >>>>>>>>>>>> error: >>>>>>>>>>>> >>>>>>>>>>>> (XEN) HVM1: Booting from 0000:7c00 >>>>>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid >>>>>>>>>>>> guest >>>>>>>>>>>> state >>>>>>>>>>>> (0). >>>>>>>>>>>> (XEN) ************* VMCS Area ************** >>>>>>>>>>>> (XEN) *** Guest State *** >>>>>>>>>>>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, >>>>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>>>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, >>>>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>>>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 >>>>>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>>>>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = >>>>>>>>>>>> 0x000000000000002a (0x000000000000002a) >>>>>>>>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = >>>>>>>>>>>> 0x0000000000000400 >>>>>>>>>>> >>>>>>>>>>> Looks like we're trying to VMENTER in virtual 8086 mode but without >>>>>>>>>>> tidying up the segment state. That could either be the guest >>>>>>>>>>> entering >>>>>>>>>>> virtual 8086 mode itself or Xen entering vitrual 8086 mode to >>>>>>>>>>> emulate >>>>>>>>>>> real mode, but Xen is always careful to make the segment state agree >>>>>>>>>>> with Intel's rather strict requrements when it does that. >>>>>>>>>>> >>>>>>>>>>> Tim. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 >>>>>>>>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, >>>>>>>>>>>> base=0x0000000000200000 >>>>>>>>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>>>>>> base=0x0000000000200000 >>>>>>>>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, >>>>>>>>>>>> base=0x000000000020ba62 >>>>>>>>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>>>>>> base=0x0000000000200000 >>>>>>>>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>>>>>> base=0x0000000000200000 >>>>>>>>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>>>>>> base=0x0000000000200000 >>>>>>>>>>>> (XEN) GDTR: limit=0x00001dd8, >>>>>>>>>>>> base=0x0000000000200000 >>>>>>>>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, >>>>>>>>>>>> base=0x0000000000000000 >>>>>>>>>>>> (XEN) IDTR: limit=0x00000188, >>>>>>>>>>>> base=0x0000000000201df0 >>>>>>>>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, >>>>>>>>>>>> base=0x0000000000201ff2 >>>>>>>>>>>> (XEN) Guest PAT = 0x0000000000000000 >>>>>>>>>>>> (XEN) TSC Offset = ffffffe4920110b7 >>>>>>>>>>>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 >>>>>>>>>>>> (XEN) Interruptibility=0001 ActivityState=0000 >>>>>>>>>>>> (XEN) *** Host State *** >>>>>>>>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 >>>>>>>>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 >>>>>>>>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 >>>>>>>>>>>> TRBase=ffff828c802a8b00 >>>>>>>>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 >>>>>>>>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 >>>>>>>>>>>> CR4=00000000000026f0 >>>>>>>>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 >>>>>>>>>>>> (XEN) Host PAT = 0x0000000000000000 >>>>>>>>>>>> (XEN) *** Control State *** >>>>>>>>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 >>>>>>>>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff >>>>>>>>>>>> (XEN) ExceptionBitmap=00044080 >>>>>>>>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 >>>>>>>>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 >>>>>>>>>>>> (XEN) reason=80000021 qualification=00000000 >>>>>>>>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 >>>>>>>>>>>> (XEN) TPR Threshold = 0x00 >>>>>>>>>>>> (XEN) EPT pointer = 0x0000000000000000 >>>>>>>>>>>> (XEN) Virtual processor ID = 0x0000 >>>>>>>>>>>> (XEN) ************************************** >>>>>>>>>>>> (XEN) domain_crash called from vmx.c:2218 >>>>>>>>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: >>>>>>>>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- >>>>>>>>>>>> (XEN) CPU: 1 >>>>>>>>>>>> (XEN) RIP: 0060:[<000000000000002a>] >>>>>>>>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest >>>>>>>>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: >>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: >>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: >>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: >>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: >>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: >>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 >>>>>>>>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: >>>>>>>>>>>> 0060 >>>>>>>>>>>> >>>>>>>>>>>> Could it be, that the real mode emulation code has a bug? What does >>>>>>>>>>>> this >>>>>>>>>>>> error means? >>>>>>>>>>>> >>>>>>>>>>>> Tom >>>>>>>>>>>> >>>>>>>>>>>> 2009/4/22 Keir Fraser >>>>>>>>>>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> >>>>>>>>>>>> On 22/04/2009 12:18, "Tom Rotenberg" >>>>>>>>>>>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Keir, >>>>>>>>>>>>> >>>>>>>>>>>>> I have applied your patch, and it seemed to work. However, the >>>>>>>>>>>>> domain >>>>>>>>>>>>> still >>>>>>>>>>>>> crashes, and now it looks like it's because of the 'LTR' >>>>>>>>>>>>> instruction. >>>>>>>>>>>> >>>>>>>>>>>> Try the attached patch. It replaces the one I sent last time, and >>>>>>>>>>>> emulates >>>>>>>>>>>> both LLDT and LTR. >>>>>>>>>>>> >>>>>>>>>>>> -- Keir >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Content-Description: ATT00001.txt >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Xen-devel mailing list >>>>>>>>>>>> Xen-devel@lists.xensource.com >>>>>>>>>>>> http://lists.xensource.com/xen-devel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Tim Deegan <Tim.Deegan@citrix.com> >>>>>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. >>>>>>>>>>> [Company #02300071, SL9 0DZ, UK.] >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Tim Deegan <Tim.Deegan@citrix.com> >>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. >>>>>>>> [Company #02300071, SL9 0DZ, UK.] >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 14:48 ` Keir Fraser @ 2009-04-22 14:53 ` Tom Rotenberg 2009-04-23 9:56 ` Tom Rotenberg 1 sibling, 0 replies; 43+ messages in thread From: Tom Rotenberg @ 2009-04-22 14:53 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 16709 bytes --] Ok, thanks for all the information. I will digg into it, and let u know, if i have any further questions. Thanks. 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > On 22/04/2009 15:40, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > So, do u have any suggestion for me, on how to advance with this issue? > should > > i debug the real mode emulation myself in order to track it down? will u > be > > able top assist me in any way with this issue? > > If specific questions arise then certainly yes. > > > BTW - what is exactly the problem which causes this exception from the > CPU? > > Tim mentioned something about segment state - can u please elaborate on > this > > issue? > > Bit 17 in EFLAGS is set, meaning the guest is in vm86 mode. In this mode, > on > vmentry, the processor applies specific checks to guest segment register > state. These are listed in SDM Vol 3B, but they include checking that > segment selector equals segment base address shifted right four bit > positions, for example. Clearly the segment state in the dump you emailed > is > not valid for vm86 mode. Quite possibly PointSec doesn't expect to be in > vm86 mode at all, and something may have gone wrong to set that bit in > EFLAGS. But it's hard to say at arm's length. > > -- Keir > > > Tom > > > > 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >> Then it probably is a mis-emulation somewhere down the line. > Unfortunately > >> that could be hard to track down, even if we had PointSec software to > hand, > >> which we do not. > >> > >> -- Keir > >> > >> On 22/04/2009 15:20, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > >> > >>> Well, just tried this patch, and it doesn't seem to work. > >>> I get the following error: > >>> > >>> (XEN) HVM1: Booting from 0000:7c00 > >>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest > state > >>> (0). > >>> (XEN) ************* VMCS Area ************** > >>> (XEN) *** Guest State *** > >>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, > >>> gh_mask=ffffffffffffffff > >>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, > >>> gh_mask=ffffffffffffffff > >>> (XEN) CR3: actual=0x000000000a22fa20, target_count=0 > >>> (XEN) target0=0000000000000000, target1=0000000000000000 > >>> (XEN) target2=0000000000000000, target3=0000000000000000 > >>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > >>> 0x000000000000002a > >>> (0x000000000000002a) > >>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > >>> 0x0000000000000400 > >>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > >>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > >>> base=0x000000000020ba62 > >>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) GDTR: limit=0x00001dd8, > >>> base=0x0000000000200000 > >>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > >>> base=0x0000000000000000 > >>> (XEN) IDTR: limit=0x00000188, > >>> base=0x0000000000201df0 > >>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > >>> base=0x0000000000201ff2 > >>> (XEN) Guest PAT = 0x0000000000000000 > >>> (XEN) TSC Offset = ffffffe2242f086e > >>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > >>> (XEN) Interruptibility=0001 ActivityState=0000 > >>> (XEN) *** Host State *** > >>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > >>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > >>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > >>> TRBase=ffff828c802a8b00 > >>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > >>> (XEN) CR0=0000000080050033 CR3=000000007cfd8000 CR4=00000000000026f0 > >>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > >>> (XEN) Host PAT = 0x0000000000000000 > >>> (XEN) *** Control State *** > >>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > >>> (XEN) EntryControls=000011ff ExitControls=0003efff > >>> (XEN) ExceptionBitmap=00044080 > >>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > >>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > >>> (XEN) reason=80000021 qualification=00000000 > >>> (XEN) IDTVectoring: info=00000000 errcode=00000000 > >>> (XEN) TPR Threshold = 0x00 > >>> (XEN) EPT pointer = 0x0000000000000000 > >>> (XEN) Virtual processor ID = 0x0000 > >>> (XEN) ************************************** > >>> (XEN) domain_crash called from vmx.c:2218 > >>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > >>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- > >>> (XEN) CPU: 1 > >>> (XEN) RIP: 0060:[<000000000000002a>] > >>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > >>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: > 0000000000000000 > >>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: > 0000000000000000 > >>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: > 0000000000000000 > >>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > 0000000000000000 > >>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > 0000000000000000 > >>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: > 0000000000000000 > >>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > >>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 > >>> > >>> > >>> Any ideas? > >>> > >>> Tom > >>> > >>> > >>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >>>> That should do it. > >>>> > >>>> K. > >>>> > >>>> > >>>> On 22/04/2009 15:04, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > >>>> > >>>>> Keir, > >>>>> Just to make sure, i am using the following patch, in order to > disable the > >>>>> vm86 acceleration: > >>>>> > >>>>> diff -r cdc044f665dc xen/arch/x86/hvm/vmx/vmx.c > >>>>> --- a/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 11:26:37 2009 +0100 > >>>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 17:03:20 2009 +0300 > >>>>> @@ -829,7 +829,7 @@ > >>>>> > >>>>> if ( seg == x86_seg_tr ) > >>>>> { > >>>>> - if ( > v->domain->arch.hvm_domain.params[HVM_PARAM_VM86_TSS] ) > >>>>> + if (0) > >>>>> { > >>>>> sel = 0; > >>>>> attr = vm86_tr_attr; > >>>>> > >>>>> Is this OK? > >>>>> > >>>>> Tom > >>>>> > >>>>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >>>>>> Yes, the safest way to be sure is probably to replace the if() > statement > >>>>>> in > >>>>>> vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with if(0). > That > >>>>>> is > >>>>>> the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can > >>>>>> re-build/install Xen and be sure that vm86 accel must be disabled. > >>>>>> > >>>>>> -- Keir > >>>>>> > >>>>>> On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@gmail.com> > wrote: > >>>>>> > >>>>>>> So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and > re-check > >>>>>>> it? > >>>>>>> > >>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>> At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: > >>>>>>>>> It could be an issue with the vm86 acceleration, possibly. I'm > pretty > >>>>>>>>> sure > >>>>>>>>> the guest would have to IRET from protected mode to enter vm86 > mode > >>>>>>>>> itself, > >>>>>>>>> and we don't emulate that. Tim: what would we need to do to > disable > >>>>>>>>> the > >>>>>>>>> vm86 > >>>>>>>>> acceleration for testing purposes? You suggested not setting > VM86_TSS > >>>>>>>>> param > >>>>>>>>> from hvmloader, but I couldn't convince myself what effect that > would > >>>>>>>>> actually have as the logic in Xen is non-trivial. > >>>>>>>> > >>>>>>>> Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() > will > >>>>>>>> always set the tss bit in the bitmap of segments that aren't safe > to > >>>>>>>> enter VM86 with. > >>>>>>>> > >>>>>>>> Tim. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> -- Keir > >>>>>>>>> > >>>>>>>>> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> > wrote: > >>>>>>>>> > >>>>>>>>>> Tim, > >>>>>>>>>> > >>>>>>>>>> so what does it mean? could it be that we have a bug in the real > mode > >>>>>>>>>> emulation, which causes the segment state to be invalid (maybe > it's > >>>>>>>>>> because > >>>>>>>>>> of > >>>>>>>>>> a bug in the patch that Keir made for me, which emulated the > LLDT, > >>>>>>>>>> and > >>>>>>>>>> the > >>>>>>>>>> LTR > >>>>>>>>>> instructions)? > >>>>>>>>>> > >>>>>>>>>> Keir suggested to trace back where the problem (segment state) > >>>>>>>>>> occured, > >>>>>>>>>> and > >>>>>>>>>> from there to try and find the bug which caused it. Do u have > any > >>>>>>>>>> better > >>>>>>>>>> suggestion for solving this? > >>>>>>>>>> > >>>>>>>>>> Tom > >>>>>>>>>> > >>>>>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>>>>> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: > >>>>>>>>>>>> Keir, > >>>>>>>>>>>> > >>>>>>>>>>>> I have tried your latest patch, and it looks like now it > passes the > >>>>>>>>>>>> emulation problem. However, now the domain crashes with the > >>>>>>>>>>>> following > >>>>>>>>>>>> error: > >>>>>>>>>>>> > >>>>>>>>>>>> (XEN) HVM1: Booting from 0000:7c00 > >>>>>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by > invalid > >>>>>>>>>>>> guest > >>>>>>>>>>>> state > >>>>>>>>>>>> (0). > >>>>>>>>>>>> (XEN) ************* VMCS Area ************** > >>>>>>>>>>>> (XEN) *** Guest State *** > >>>>>>>>>>>> (XEN) CR0: actual=0x0000000080010039, > shadow=0x0000000080000019, > >>>>>>>>>>>> gh_mask=ffffffffffffffff > >>>>>>>>>>>> (XEN) CR4: actual=0x0000000000002060, > shadow=0x0000000000000000, > >>>>>>>>>>>> gh_mask=ffffffffffffffff > >>>>>>>>>>>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 > >>>>>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 > >>>>>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 > >>>>>>>>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > >>>>>>>>>>>> 0x000000000000002a (0x000000000000002a) > >>>>>>>>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > >>>>>>>>>>>> 0x0000000000000400 > >>>>>>>>>>> > >>>>>>>>>>> Looks like we're trying to VMENTER in virtual 8086 mode but > without > >>>>>>>>>>> tidying up the segment state. That could either be the guest > >>>>>>>>>>> entering > >>>>>>>>>>> virtual 8086 mode itself or Xen entering vitrual 8086 mode to > >>>>>>>>>>> emulate > >>>>>>>>>>> real mode, but Xen is always careful to make the segment state > agree > >>>>>>>>>>> with Intel's rather strict requrements when it does that. > >>>>>>>>>>> > >>>>>>>>>>> Tim. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> (XEN) Sysenter RSP=0000000000000000 > CS:RIP=0000:0000000000000000 > >>>>>>>>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > >>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > >>>>>>>>>>>> base=0x000000000020ba62 > >>>>>>>>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>> (XEN) GDTR: limit=0x00001dd8, > >>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > >>>>>>>>>>>> base=0x0000000000000000 > >>>>>>>>>>>> (XEN) IDTR: limit=0x00000188, > >>>>>>>>>>>> base=0x0000000000201df0 > >>>>>>>>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > >>>>>>>>>>>> base=0x0000000000201ff2 > >>>>>>>>>>>> (XEN) Guest PAT = 0x0000000000000000 > >>>>>>>>>>>> (XEN) TSC Offset = ffffffe4920110b7 > >>>>>>>>>>>> (XEN) DebugCtl=0000000000000000 > DebugExceptions=0000000000000000 > >>>>>>>>>>>> (XEN) Interruptibility=0001 ActivityState=0000 > >>>>>>>>>>>> (XEN) *** Host State *** > >>>>>>>>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > >>>>>>>>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > >>>>>>>>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > >>>>>>>>>>>> TRBase=ffff828c802a8b00 > >>>>>>>>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > >>>>>>>>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 > >>>>>>>>>>>> CR4=00000000000026f0 > >>>>>>>>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 > CS:RIP=e008:ffff828c801c7290 > >>>>>>>>>>>> (XEN) Host PAT = 0x0000000000000000 > >>>>>>>>>>>> (XEN) *** Control State *** > >>>>>>>>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe > SecondaryExec=00000041 > >>>>>>>>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff > >>>>>>>>>>>> (XEN) ExceptionBitmap=00044080 > >>>>>>>>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac > ilen=00000000 > >>>>>>>>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 > ilen=00000000 > >>>>>>>>>>>> (XEN) reason=80000021 qualification=00000000 > >>>>>>>>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 > >>>>>>>>>>>> (XEN) TPR Threshold = 0x00 > >>>>>>>>>>>> (XEN) EPT pointer = 0x0000000000000000 > >>>>>>>>>>>> (XEN) Virtual processor ID = 0x0000 > >>>>>>>>>>>> (XEN) ************************************** > >>>>>>>>>>>> (XEN) domain_crash called from vmx.c:2218 > >>>>>>>>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > >>>>>>>>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted > ]---- > >>>>>>>>>>>> (XEN) CPU: 1 > >>>>>>>>>>>> (XEN) RIP: 0060:[<000000000000002a>] > >>>>>>>>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > >>>>>>>>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: > >>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: > >>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: > >>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > >>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > >>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: > >>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > >>>>>>>>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 > cs: > >>>>>>>>>>>> 0060 > >>>>>>>>>>>> > >>>>>>>>>>>> Could it be, that the real mode emulation code has a bug? What > does > >>>>>>>>>>>> this > >>>>>>>>>>>> error means? > >>>>>>>>>>>> > >>>>>>>>>>>> Tom > >>>>>>>>>>>> > >>>>>>>>>>>> 2009/4/22 Keir Fraser > >>>>>>>>>>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> > >>>>>>>>>>>> On 22/04/2009 12:18, "Tom Rotenberg" > >>>>>>>>>>>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> > wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Keir, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I have applied your patch, and it seemed to work. However, > the > >>>>>>>>>>>>> domain > >>>>>>>>>>>>> still > >>>>>>>>>>>>> crashes, and now it looks like it's because of the 'LTR' > >>>>>>>>>>>>> instruction. > >>>>>>>>>>>> > >>>>>>>>>>>> Try the attached patch. It replaces the one I sent last time, > and > >>>>>>>>>>>> emulates > >>>>>>>>>>>> both LLDT and LTR. > >>>>>>>>>>>> > >>>>>>>>>>>> -- Keir > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Content-Description: ATT00001.txt > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> Xen-devel mailing list > >>>>>>>>>>>> Xen-devel@lists.xensource.com > >>>>>>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >>>>>>>>>>> [Company #02300071, SL9 0DZ, UK.] > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >>>>>>>> [Company #02300071, SL9 0DZ, UK.] > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > > > > > [-- Attachment #1.2: Type: text/html, Size: 27550 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-22 14:48 ` Keir Fraser 2009-04-22 14:53 ` Tom Rotenberg @ 2009-04-23 9:56 ` Tom Rotenberg 2009-04-23 10:42 ` Keir Fraser 1 sibling, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-23 9:56 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 16891 bytes --] Keir, Is there any tool, which allows debugging step by step of the boot sequence (starting from the point which the hvmloader transfers control to the MBR)? If there is such tool, i will be able to debug it step by step, and compare it to a real machine, and thus, hopefully find the bug. Tom 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > On 22/04/2009 15:40, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > So, do u have any suggestion for me, on how to advance with this issue? > should > > i debug the real mode emulation myself in order to track it down? will u > be > > able top assist me in any way with this issue? > > If specific questions arise then certainly yes. > > > BTW - what is exactly the problem which causes this exception from the > CPU? > > Tim mentioned something about segment state - can u please elaborate on > this > > issue? > > Bit 17 in EFLAGS is set, meaning the guest is in vm86 mode. In this mode, > on > vmentry, the processor applies specific checks to guest segment register > state. These are listed in SDM Vol 3B, but they include checking that > segment selector equals segment base address shifted right four bit > positions, for example. Clearly the segment state in the dump you emailed > is > not valid for vm86 mode. Quite possibly PointSec doesn't expect to be in > vm86 mode at all, and something may have gone wrong to set that bit in > EFLAGS. But it's hard to say at arm's length. > > -- Keir > > > Tom > > > > 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >> Then it probably is a mis-emulation somewhere down the line. > Unfortunately > >> that could be hard to track down, even if we had PointSec software to > hand, > >> which we do not. > >> > >> -- Keir > >> > >> On 22/04/2009 15:20, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > >> > >>> Well, just tried this patch, and it doesn't seem to work. > >>> I get the following error: > >>> > >>> (XEN) HVM1: Booting from 0000:7c00 > >>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest > state > >>> (0). > >>> (XEN) ************* VMCS Area ************** > >>> (XEN) *** Guest State *** > >>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, > >>> gh_mask=ffffffffffffffff > >>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, > >>> gh_mask=ffffffffffffffff > >>> (XEN) CR3: actual=0x000000000a22fa20, target_count=0 > >>> (XEN) target0=0000000000000000, target1=0000000000000000 > >>> (XEN) target2=0000000000000000, target3=0000000000000000 > >>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > >>> 0x000000000000002a > >>> (0x000000000000002a) > >>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > >>> 0x0000000000000400 > >>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > >>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > >>> base=0x000000000020ba62 > >>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>> base=0x0000000000200000 > >>> (XEN) GDTR: limit=0x00001dd8, > >>> base=0x0000000000200000 > >>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > >>> base=0x0000000000000000 > >>> (XEN) IDTR: limit=0x00000188, > >>> base=0x0000000000201df0 > >>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > >>> base=0x0000000000201ff2 > >>> (XEN) Guest PAT = 0x0000000000000000 > >>> (XEN) TSC Offset = ffffffe2242f086e > >>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > >>> (XEN) Interruptibility=0001 ActivityState=0000 > >>> (XEN) *** Host State *** > >>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > >>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > >>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > >>> TRBase=ffff828c802a8b00 > >>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > >>> (XEN) CR0=0000000080050033 CR3=000000007cfd8000 CR4=00000000000026f0 > >>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > >>> (XEN) Host PAT = 0x0000000000000000 > >>> (XEN) *** Control State *** > >>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > >>> (XEN) EntryControls=000011ff ExitControls=0003efff > >>> (XEN) ExceptionBitmap=00044080 > >>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > >>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > >>> (XEN) reason=80000021 qualification=00000000 > >>> (XEN) IDTVectoring: info=00000000 errcode=00000000 > >>> (XEN) TPR Threshold = 0x00 > >>> (XEN) EPT pointer = 0x0000000000000000 > >>> (XEN) Virtual processor ID = 0x0000 > >>> (XEN) ************************************** > >>> (XEN) domain_crash called from vmx.c:2218 > >>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > >>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- > >>> (XEN) CPU: 1 > >>> (XEN) RIP: 0060:[<000000000000002a>] > >>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > >>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: > 0000000000000000 > >>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: > 0000000000000000 > >>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: > 0000000000000000 > >>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > 0000000000000000 > >>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > 0000000000000000 > >>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: > 0000000000000000 > >>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > >>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 > >>> > >>> > >>> Any ideas? > >>> > >>> Tom > >>> > >>> > >>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >>>> That should do it. > >>>> > >>>> K. > >>>> > >>>> > >>>> On 22/04/2009 15:04, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > >>>> > >>>>> Keir, > >>>>> Just to make sure, i am using the following patch, in order to > disable the > >>>>> vm86 acceleration: > >>>>> > >>>>> diff -r cdc044f665dc xen/arch/x86/hvm/vmx/vmx.c > >>>>> --- a/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 11:26:37 2009 +0100 > >>>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 17:03:20 2009 +0300 > >>>>> @@ -829,7 +829,7 @@ > >>>>> > >>>>> if ( seg == x86_seg_tr ) > >>>>> { > >>>>> - if ( > v->domain->arch.hvm_domain.params[HVM_PARAM_VM86_TSS] ) > >>>>> + if (0) > >>>>> { > >>>>> sel = 0; > >>>>> attr = vm86_tr_attr; > >>>>> > >>>>> Is this OK? > >>>>> > >>>>> Tom > >>>>> > >>>>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >>>>>> Yes, the safest way to be sure is probably to replace the if() > statement > >>>>>> in > >>>>>> vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with if(0). > That > >>>>>> is > >>>>>> the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can > >>>>>> re-build/install Xen and be sure that vm86 accel must be disabled. > >>>>>> > >>>>>> -- Keir > >>>>>> > >>>>>> On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@gmail.com> > wrote: > >>>>>> > >>>>>>> So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and > re-check > >>>>>>> it? > >>>>>>> > >>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>> At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: > >>>>>>>>> It could be an issue with the vm86 acceleration, possibly. I'm > pretty > >>>>>>>>> sure > >>>>>>>>> the guest would have to IRET from protected mode to enter vm86 > mode > >>>>>>>>> itself, > >>>>>>>>> and we don't emulate that. Tim: what would we need to do to > disable > >>>>>>>>> the > >>>>>>>>> vm86 > >>>>>>>>> acceleration for testing purposes? You suggested not setting > VM86_TSS > >>>>>>>>> param > >>>>>>>>> from hvmloader, but I couldn't convince myself what effect that > would > >>>>>>>>> actually have as the logic in Xen is non-trivial. > >>>>>>>> > >>>>>>>> Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() > will > >>>>>>>> always set the tss bit in the bitmap of segments that aren't safe > to > >>>>>>>> enter VM86 with. > >>>>>>>> > >>>>>>>> Tim. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> -- Keir > >>>>>>>>> > >>>>>>>>> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> > wrote: > >>>>>>>>> > >>>>>>>>>> Tim, > >>>>>>>>>> > >>>>>>>>>> so what does it mean? could it be that we have a bug in the real > mode > >>>>>>>>>> emulation, which causes the segment state to be invalid (maybe > it's > >>>>>>>>>> because > >>>>>>>>>> of > >>>>>>>>>> a bug in the patch that Keir made for me, which emulated the > LLDT, > >>>>>>>>>> and > >>>>>>>>>> the > >>>>>>>>>> LTR > >>>>>>>>>> instructions)? > >>>>>>>>>> > >>>>>>>>>> Keir suggested to trace back where the problem (segment state) > >>>>>>>>>> occured, > >>>>>>>>>> and > >>>>>>>>>> from there to try and find the bug which caused it. Do u have > any > >>>>>>>>>> better > >>>>>>>>>> suggestion for solving this? > >>>>>>>>>> > >>>>>>>>>> Tom > >>>>>>>>>> > >>>>>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>>>>> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: > >>>>>>>>>>>> Keir, > >>>>>>>>>>>> > >>>>>>>>>>>> I have tried your latest patch, and it looks like now it > passes the > >>>>>>>>>>>> emulation problem. However, now the domain crashes with the > >>>>>>>>>>>> following > >>>>>>>>>>>> error: > >>>>>>>>>>>> > >>>>>>>>>>>> (XEN) HVM1: Booting from 0000:7c00 > >>>>>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by > invalid > >>>>>>>>>>>> guest > >>>>>>>>>>>> state > >>>>>>>>>>>> (0). > >>>>>>>>>>>> (XEN) ************* VMCS Area ************** > >>>>>>>>>>>> (XEN) *** Guest State *** > >>>>>>>>>>>> (XEN) CR0: actual=0x0000000080010039, > shadow=0x0000000080000019, > >>>>>>>>>>>> gh_mask=ffffffffffffffff > >>>>>>>>>>>> (XEN) CR4: actual=0x0000000000002060, > shadow=0x0000000000000000, > >>>>>>>>>>>> gh_mask=ffffffffffffffff > >>>>>>>>>>>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 > >>>>>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 > >>>>>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 > >>>>>>>>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > >>>>>>>>>>>> 0x000000000000002a (0x000000000000002a) > >>>>>>>>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > >>>>>>>>>>>> 0x0000000000000400 > >>>>>>>>>>> > >>>>>>>>>>> Looks like we're trying to VMENTER in virtual 8086 mode but > without > >>>>>>>>>>> tidying up the segment state. That could either be the guest > >>>>>>>>>>> entering > >>>>>>>>>>> virtual 8086 mode itself or Xen entering vitrual 8086 mode to > >>>>>>>>>>> emulate > >>>>>>>>>>> real mode, but Xen is always careful to make the segment state > agree > >>>>>>>>>>> with Intel's rather strict requrements when it does that. > >>>>>>>>>>> > >>>>>>>>>>> Tim. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> (XEN) Sysenter RSP=0000000000000000 > CS:RIP=0000:0000000000000000 > >>>>>>>>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > >>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > >>>>>>>>>>>> base=0x000000000020ba62 > >>>>>>>>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>> (XEN) GDTR: limit=0x00001dd8, > >>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > >>>>>>>>>>>> base=0x0000000000000000 > >>>>>>>>>>>> (XEN) IDTR: limit=0x00000188, > >>>>>>>>>>>> base=0x0000000000201df0 > >>>>>>>>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > >>>>>>>>>>>> base=0x0000000000201ff2 > >>>>>>>>>>>> (XEN) Guest PAT = 0x0000000000000000 > >>>>>>>>>>>> (XEN) TSC Offset = ffffffe4920110b7 > >>>>>>>>>>>> (XEN) DebugCtl=0000000000000000 > DebugExceptions=0000000000000000 > >>>>>>>>>>>> (XEN) Interruptibility=0001 ActivityState=0000 > >>>>>>>>>>>> (XEN) *** Host State *** > >>>>>>>>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > >>>>>>>>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > >>>>>>>>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > >>>>>>>>>>>> TRBase=ffff828c802a8b00 > >>>>>>>>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > >>>>>>>>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 > >>>>>>>>>>>> CR4=00000000000026f0 > >>>>>>>>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 > CS:RIP=e008:ffff828c801c7290 > >>>>>>>>>>>> (XEN) Host PAT = 0x0000000000000000 > >>>>>>>>>>>> (XEN) *** Control State *** > >>>>>>>>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe > SecondaryExec=00000041 > >>>>>>>>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff > >>>>>>>>>>>> (XEN) ExceptionBitmap=00044080 > >>>>>>>>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac > ilen=00000000 > >>>>>>>>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 > ilen=00000000 > >>>>>>>>>>>> (XEN) reason=80000021 qualification=00000000 > >>>>>>>>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 > >>>>>>>>>>>> (XEN) TPR Threshold = 0x00 > >>>>>>>>>>>> (XEN) EPT pointer = 0x0000000000000000 > >>>>>>>>>>>> (XEN) Virtual processor ID = 0x0000 > >>>>>>>>>>>> (XEN) ************************************** > >>>>>>>>>>>> (XEN) domain_crash called from vmx.c:2218 > >>>>>>>>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > >>>>>>>>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted > ]---- > >>>>>>>>>>>> (XEN) CPU: 1 > >>>>>>>>>>>> (XEN) RIP: 0060:[<000000000000002a>] > >>>>>>>>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > >>>>>>>>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: > >>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: > >>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: > >>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > >>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > >>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: > >>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > >>>>>>>>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 > cs: > >>>>>>>>>>>> 0060 > >>>>>>>>>>>> > >>>>>>>>>>>> Could it be, that the real mode emulation code has a bug? What > does > >>>>>>>>>>>> this > >>>>>>>>>>>> error means? > >>>>>>>>>>>> > >>>>>>>>>>>> Tom > >>>>>>>>>>>> > >>>>>>>>>>>> 2009/4/22 Keir Fraser > >>>>>>>>>>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> > >>>>>>>>>>>> On 22/04/2009 12:18, "Tom Rotenberg" > >>>>>>>>>>>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> > wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Keir, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I have applied your patch, and it seemed to work. However, > the > >>>>>>>>>>>>> domain > >>>>>>>>>>>>> still > >>>>>>>>>>>>> crashes, and now it looks like it's because of the 'LTR' > >>>>>>>>>>>>> instruction. > >>>>>>>>>>>> > >>>>>>>>>>>> Try the attached patch. It replaces the one I sent last time, > and > >>>>>>>>>>>> emulates > >>>>>>>>>>>> both LLDT and LTR. > >>>>>>>>>>>> > >>>>>>>>>>>> -- Keir > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Content-Description: ATT00001.txt > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> Xen-devel mailing list > >>>>>>>>>>>> Xen-devel@lists.xensource.com > >>>>>>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >>>>>>>>>>> [Company #02300071, SL9 0DZ, UK.] > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >>>>>>>> [Company #02300071, SL9 0DZ, UK.] > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > > > > > [-- Attachment #1.2: Type: text/html, Size: 27744 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 9:56 ` Tom Rotenberg @ 2009-04-23 10:42 ` Keir Fraser 2009-04-23 11:44 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-23 10:42 UTC (permalink / raw) To: Tom Rotenberg; +Cc: Tim Deegan, xen-devel@lists.xensource.com I don't think we have anything obvious for dealing with single stepping of real mode and 16-bit protected mode. Not to mention that sometimes these bugs occur after execution of many thousands of instructions, which makes a single step approach impractical. -- Keir On 23/04/2009 10:56, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > Keir, > > Is there any tool, which allows debugging step by step of the boot sequence > (starting from the point which the hvmloader transfers control to the MBR)? > If there is such tool, i will be able to debug it step by step, and compare it > to a real machine, and thus, hopefully find the bug. > > Tom > > 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> >> On 22/04/2009 15:40, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >> >>> So, do u have any suggestion for me, on how to advance with this issue? >>> should >>> i debug the real mode emulation myself in order to track it down? will u be >>> able top assist me in any way with this issue? >> >> If specific questions arise then certainly yes. >> >>> BTW - what is exactly the problem which causes this exception from the CPU? >>> Tim mentioned something about segment state - can u please elaborate on this >>> issue? >> >> Bit 17 in EFLAGS is set, meaning the guest is in vm86 mode. In this mode, on >> vmentry, the processor applies specific checks to guest segment register >> state. These are listed in SDM Vol 3B, but they include checking that >> segment selector equals segment base address shifted right four bit >> positions, for example. Clearly the segment state in the dump you emailed is >> not valid for vm86 mode. Quite possibly PointSec doesn't expect to be in >> vm86 mode at all, and something may have gone wrong to set that bit in >> EFLAGS. But it's hard to say at arm's length. >> >> -- Keir >> >>> Tom >>> >>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> >>>> Then it probably is a mis-emulation somewhere down the line. Unfortunately >>>> that could be hard to track down, even if we had PointSec software to hand, >>>> which we do not. >>>> >>>> -- Keir >>>> >>>> On 22/04/2009 15:20, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >>>> >>>>> Well, just tried this patch, and it doesn't seem to work. >>>>> I get the following error: >>>>> >>>>> (XEN) HVM1: Booting from 0000:7c00 >>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>>>> state >>>>> (0). >>>>> (XEN) ************* VMCS Area ************** >>>>> (XEN) *** Guest State *** >>>>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, >>>>> gh_mask=ffffffffffffffff >>>>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, >>>>> gh_mask=ffffffffffffffff >>>>> (XEN) CR3: actual=0x000000000a22fa20, target_count=0 >>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = >>>>> 0x000000000000002a >>>>> (0x000000000000002a) >>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = >>>>> 0x0000000000000400 >>>>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 >>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, >>>>> base=0x0000000000200000 >>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>> base=0x0000000000200000 >>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, >>>>> base=0x000000000020ba62 >>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>> base=0x0000000000200000 >>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>> base=0x0000000000200000 >>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>> base=0x0000000000200000 >>>>> (XEN) GDTR: limit=0x00001dd8, >>>>> base=0x0000000000200000 >>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, >>>>> base=0x0000000000000000 >>>>> (XEN) IDTR: limit=0x00000188, >>>>> base=0x0000000000201df0 >>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, >>>>> base=0x0000000000201ff2 >>>>> (XEN) Guest PAT = 0x0000000000000000 >>>>> (XEN) TSC Offset = ffffffe2242f086e >>>>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 >>>>> (XEN) Interruptibility=0001 ActivityState=0000 >>>>> (XEN) *** Host State *** >>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 >>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 >>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 >>>>> TRBase=ffff828c802a8b00 >>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 >>>>> (XEN) CR0=0000000080050033 CR3=000000007cfd8000 CR4=00000000000026f0 >>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 >>>>> (XEN) Host PAT = 0x0000000000000000 >>>>> (XEN) *** Control State *** >>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 >>>>> (XEN) EntryControls=000011ff ExitControls=0003efff >>>>> (XEN) ExceptionBitmap=00044080 >>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 >>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 >>>>> (XEN) reason=80000021 qualification=00000000 >>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 >>>>> (XEN) TPR Threshold = 0x00 >>>>> (XEN) EPT pointer = 0x0000000000000000 >>>>> (XEN) Virtual processor ID = 0x0000 >>>>> (XEN) ************************************** >>>>> (XEN) domain_crash called from vmx.c:2218 >>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: >>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- >>>>> (XEN) CPU: 1 >>>>> (XEN) RIP: 0060:[<000000000000002a>] >>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest >>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: >>>>> 0000000000000000 >>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: >>>>> 0000000000000000 >>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: >>>>> 0000000000000000 >>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: >>>>> 0000000000000000 >>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: >>>>> 0000000000000000 >>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: >>>>> 0000000000000000 >>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 >>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 >>>>> >>>>> >>>>> Any ideas? >>>>> >>>>> Tom >>>>> >>>>> >>>>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> >>>>>> That should do it. >>>>>> >>>>>> K. >>>>>> >>>>>> >>>>>> On 22/04/2009 15:04, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >>>>>> >>>>>>> Keir, >>>>>>> Just to make sure, i am using the following patch, in order to disable >>>>>>> the >>>>>>> vm86 acceleration: >>>>>>> >>>>>>> diff -r cdc044f665dc xen/arch/x86/hvm/vmx/vmx.c >>>>>>> --- a/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 11:26:37 2009 +0100 >>>>>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 17:03:20 2009 +0300 >>>>>>> @@ -829,7 +829,7 @@ >>>>>>> >>>>>>> if ( seg == x86_seg_tr ) >>>>>>> { >>>>>>> - if ( v->domain->arch.hvm_domain.params[HVM_PARAM_VM86_TSS] >>>>>>> ) >>>>>>> + if (0) >>>>>>> { >>>>>>> sel = 0; >>>>>>> attr = vm86_tr_attr; >>>>>>> >>>>>>> Is this OK? >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> >>>>>>>> Yes, the safest way to be sure is probably to replace the if() >>>>>>>> statement >>>>>>>> in >>>>>>>> vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with if(0). >>>>>>>> That >>>>>>>> is >>>>>>>> the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can >>>>>>>> re-build/install Xen and be sure that vm86 accel must be disabled. >>>>>>>> >>>>>>>> -- Keir >>>>>>>> >>>>>>>> On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >>>>>>>> >>>>>>>>> So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and >>>>>>>>> re-check >>>>>>>>> it? >>>>>>>>> >>>>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> >>>>>>>>>> At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: >>>>>>>>>>> It could be an issue with the vm86 acceleration, possibly. I'm >>>>>>>>>>> pretty >>>>>>>>>>> sure >>>>>>>>>>> the guest would have to IRET from protected mode to enter vm86 mode >>>>>>>>>>> itself, >>>>>>>>>>> and we don't emulate that. Tim: what would we need to do to disable >>>>>>>>>>> the >>>>>>>>>>> vm86 >>>>>>>>>>> acceleration for testing purposes? You suggested not setting >>>>>>>>>>> VM86_TSS >>>>>>>>>>> param >>>>>>>>>>> from hvmloader, but I couldn't convince myself what effect that >>>>>>>>>>> would >>>>>>>>>>> actually have as the logic in Xen is non-trivial. >>>>>>>>>> >>>>>>>>>> Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() will >>>>>>>>>> always set the tss bit in the bitmap of segments that aren't safe to >>>>>>>>>> enter VM86 with. >>>>>>>>>> >>>>>>>>>> Tim. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- Keir >>>>>>>>>>> >>>>>>>>>>> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Tim, >>>>>>>>>>>> >>>>>>>>>>>> so what does it mean? could it be that we have a bug in the real >>>>>>>>>>>> mode >>>>>>>>>>>> emulation, which causes the segment state to be invalid (maybe it's >>>>>>>>>>>> because >>>>>>>>>>>> of >>>>>>>>>>>> a bug in the patch that Keir made for me, which emulated the LLDT, >>>>>>>>>>>> and >>>>>>>>>>>> the >>>>>>>>>>>> LTR >>>>>>>>>>>> instructions)? >>>>>>>>>>>> >>>>>>>>>>>> Keir suggested to trace back where the problem (segment state) >>>>>>>>>>>> occured, >>>>>>>>>>>> and >>>>>>>>>>>> from there to try and find the bug which caused it. Do u have any >>>>>>>>>>>> better >>>>>>>>>>>> suggestion for solving this? >>>>>>>>>>>> >>>>>>>>>>>> Tom >>>>>>>>>>>> >>>>>>>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> >>>>>>>>>>>>> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: >>>>>>>>>>>>> Keir, >>>>>>>>>>>>> >>>>>>>>>>>>> I have tried your latest patch, and it looks like now it passes >>>>>>>>>>>>> the >>>>>>>>>>>>> emulation problem. However, now the domain crashes with the >>>>>>>>>>>>> following >>>>>>>>>>>>> error: >>>>>>>>>>>>> >>>>>>>>>>>>> (XEN) HVM1: Booting from 0000:7c00 >>>>>>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid >>>>>>>>>>>>> guest >>>>>>>>>>>>> state >>>>>>>>>>>>> (0). >>>>>>>>>>>>> (XEN) ************* VMCS Area ************** >>>>>>>>>>>>> (XEN) *** Guest State *** >>>>>>>>>>>>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, >>>>>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>>>>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, >>>>>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>>>>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 >>>>>>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>>>>>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = >>>>>>>>>>>>> 0x000000000000002a (0x000000000000002a) >>>>>>>>>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = >>>>>>>>>>>>> 0x0000000000000400 >>>>>>>>>>>>> >>>>>>>>>>>>> Looks like we're trying to VMENTER in virtual 8086 mode but >>>>>>>>>>>>> without >>>>>>>>>>>>> tidying up the segment state. That could either be the guest >>>>>>>>>>>>> entering >>>>>>>>>>>>> virtual 8086 mode itself or Xen entering vitrual 8086 mode to >>>>>>>>>>>>> emulate >>>>>>>>>>>>> real mode, but Xen is always careful to make the segment state >>>>>>>>>>>>> agree >>>>>>>>>>>>> with Intel's rather strict requrements when it does that. >>>>>>>>>>>>> >>>>>>>>>>>>> Tim. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 >>>>>>>>>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, >>>>>>>>>>>>> base=0x0000000000200000 >>>>>>>>>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>>>>>>> base=0x0000000000200000 >>>>>>>>>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, >>>>>>>>>>>>> base=0x000000000020ba62 >>>>>>>>>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>>>>>>> base=0x0000000000200000 >>>>>>>>>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>>>>>>> base=0x0000000000200000 >>>>>>>>>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, >>>>>>>>>>>>> base=0x0000000000200000 >>>>>>>>>>>>> (XEN) GDTR: limit=0x00001dd8, >>>>>>>>>>>>> base=0x0000000000200000 >>>>>>>>>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, >>>>>>>>>>>>> base=0x0000000000000000 >>>>>>>>>>>>> (XEN) IDTR: limit=0x00000188, >>>>>>>>>>>>> base=0x0000000000201df0 >>>>>>>>>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, >>>>>>>>>>>>> base=0x0000000000201ff2 >>>>>>>>>>>>> (XEN) Guest PAT = 0x0000000000000000 >>>>>>>>>>>>> (XEN) TSC Offset = ffffffe4920110b7 >>>>>>>>>>>>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 >>>>>>>>>>>>> (XEN) Interruptibility=0001 ActivityState=0000 >>>>>>>>>>>>> (XEN) *** Host State *** >>>>>>>>>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 >>>>>>>>>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 >>>>>>>>>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 >>>>>>>>>>>>> TRBase=ffff828c802a8b00 >>>>>>>>>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 >>>>>>>>>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 >>>>>>>>>>>>> CR4=00000000000026f0 >>>>>>>>>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 >>>>>>>>>>>>> (XEN) Host PAT = 0x0000000000000000 >>>>>>>>>>>>> (XEN) *** Control State *** >>>>>>>>>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 >>>>>>>>>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff >>>>>>>>>>>>> (XEN) ExceptionBitmap=00044080 >>>>>>>>>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 >>>>>>>>>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 >>>>>>>>>>>>> (XEN) reason=80000021 qualification=00000000 >>>>>>>>>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 >>>>>>>>>>>>> (XEN) TPR Threshold = 0x00 >>>>>>>>>>>>> (XEN) EPT pointer = 0x0000000000000000 >>>>>>>>>>>>> (XEN) Virtual processor ID = 0x0000 >>>>>>>>>>>>> (XEN) ************************************** >>>>>>>>>>>>> (XEN) domain_crash called from vmx.c:2218 >>>>>>>>>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: >>>>>>>>>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- >>>>>>>>>>>>> (XEN) CPU: 1 >>>>>>>>>>>>> (XEN) RIP: 0060:[<000000000000002a>] >>>>>>>>>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest >>>>>>>>>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: >>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: >>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: >>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: >>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: >>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: >>>>>>>>>>>>> 0000000000000000 >>>>>>>>>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 >>>>>>>>>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: >>>>>>>>>>>>> 0060 >>>>>>>>>>>>> >>>>>>>>>>>>> Could it be, that the real mode emulation code has a bug? What >>>>>>>>>>>>> does >>>>>>>>>>>>> this >>>>>>>>>>>>> error means? >>>>>>>>>>>>> >>>>>>>>>>>>> Tom >>>>>>>>>>>>> >>>>>>>>>>>>> 2009/4/22 Keir Fraser >>>>>>>>>>>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> >>>>>>>>>>>>> On 22/04/2009 12:18, "Tom Rotenberg" >>>>>>>>>>>>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Keir, >>>>>>>>>>>>> >>>>>>>>>>>>> I have applied your patch, and it seemed to work. However, the >>>>>>>>>>>>> domain >>>>>>>>>>>>> still >>>>>>>>>>>>> crashes, and now it looks like it's because of the 'LTR' >>>>>>>>>>>>> instruction. >>>>>>>>>>>>> >>>>>>>>>>>>> Try the attached patch. It replaces the one I sent last time, and >>>>>>>>>>>>> emulates >>>>>>>>>>>>> both LLDT and LTR. >>>>>>>>>>>>> >>>>>>>>>>>>> -- Keir >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Content-Description: ATT00001.txt >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Xen-devel mailing list >>>>>>>>>>>>> Xen-devel@lists.xensource.com >>>>>>>>>>>>> http://lists.xensource.com/xen-devel >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Tim Deegan <Tim.Deegan@citrix.com> >>>>>>>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. >>>>>>>>>>>>> [Company #02300071, SL9 0DZ, UK.] >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Tim Deegan <Tim.Deegan@citrix.com> >>>>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. >>>>>>>>>> [Company #02300071, SL9 0DZ, UK.] >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 10:42 ` Keir Fraser @ 2009-04-23 11:44 ` Tom Rotenberg 2009-04-23 12:15 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-23 11:44 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 18924 bytes --] OK. BTW - i am starting to digg this up, and i saw, that the LLDT instruction was done with value of 0, meaning (according to Intel spec), to mark the LDTR as invalid. After that the LTR instruction was done with value (AX) of 0x50. However, from the VMCS dump, i saw data, which doesn't seem compatible with this, as the LDTR sellector is indeed 0, but has attributes and limit different from zero (although it should have been totaly disabled, by the LLDT, no?). And more important, the TR selector is 0x58, although from the LTR, it was supposed to be 0x50, no? (of-course it's possible that there were other instructions who changed it back, however, i am wondering if there is a problem here). Tom 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com> > I don't think we have anything obvious for dealing with single stepping of > real mode and 16-bit protected mode. Not to mention that sometimes these > bugs occur after execution of many thousands of instructions, which makes a > single step approach impractical. > > -- Keir > > On 23/04/2009 10:56, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > Keir, > > > > Is there any tool, which allows debugging step by step of the boot > sequence > > (starting from the point which the hvmloader transfers control to the > MBR)? > > If there is such tool, i will be able to debug it step by step, and > compare it > > to a real machine, and thus, hopefully find the bug. > > > > Tom > > > > 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >> On 22/04/2009 15:40, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > >> > >>> So, do u have any suggestion for me, on how to advance with this issue? > >>> should > >>> i debug the real mode emulation myself in order to track it down? will > u be > >>> able top assist me in any way with this issue? > >> > >> If specific questions arise then certainly yes. > >> > >>> BTW - what is exactly the problem which causes this exception from the > CPU? > >>> Tim mentioned something about segment state - can u please elaborate on > this > >>> issue? > >> > >> Bit 17 in EFLAGS is set, meaning the guest is in vm86 mode. In this > mode, on > >> vmentry, the processor applies specific checks to guest segment register > >> state. These are listed in SDM Vol 3B, but they include checking that > >> segment selector equals segment base address shifted right four bit > >> positions, for example. Clearly the segment state in the dump you > emailed is > >> not valid for vm86 mode. Quite possibly PointSec doesn't expect to be in > >> vm86 mode at all, and something may have gone wrong to set that bit in > >> EFLAGS. But it's hard to say at arm's length. > >> > >> -- Keir > >> > >>> Tom > >>> > >>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >>>> Then it probably is a mis-emulation somewhere down the line. > Unfortunately > >>>> that could be hard to track down, even if we had PointSec software to > hand, > >>>> which we do not. > >>>> > >>>> -- Keir > >>>> > >>>> On 22/04/2009 15:20, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > >>>> > >>>>> Well, just tried this patch, and it doesn't seem to work. > >>>>> I get the following error: > >>>>> > >>>>> (XEN) HVM1: Booting from 0000:7c00 > >>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid > guest > >>>>> state > >>>>> (0). > >>>>> (XEN) ************* VMCS Area ************** > >>>>> (XEN) *** Guest State *** > >>>>> (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, > >>>>> gh_mask=ffffffffffffffff > >>>>> (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, > >>>>> gh_mask=ffffffffffffffff > >>>>> (XEN) CR3: actual=0x000000000a22fa20, target_count=0 > >>>>> (XEN) target0=0000000000000000, target1=0000000000000000 > >>>>> (XEN) target2=0000000000000000, target3=0000000000000000 > >>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > >>>>> 0x000000000000002a > >>>>> (0x000000000000002a) > >>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > >>>>> 0x0000000000000400 > >>>>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > >>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > >>>>> base=0x0000000000200000 > >>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>> base=0x0000000000200000 > >>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > >>>>> base=0x000000000020ba62 > >>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>> base=0x0000000000200000 > >>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>> base=0x0000000000200000 > >>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>> base=0x0000000000200000 > >>>>> (XEN) GDTR: limit=0x00001dd8, > >>>>> base=0x0000000000200000 > >>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > >>>>> base=0x0000000000000000 > >>>>> (XEN) IDTR: limit=0x00000188, > >>>>> base=0x0000000000201df0 > >>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > >>>>> base=0x0000000000201ff2 > >>>>> (XEN) Guest PAT = 0x0000000000000000 > >>>>> (XEN) TSC Offset = ffffffe2242f086e > >>>>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 > >>>>> (XEN) Interruptibility=0001 ActivityState=0000 > >>>>> (XEN) *** Host State *** > >>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > >>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > >>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > >>>>> TRBase=ffff828c802a8b00 > >>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > >>>>> (XEN) CR0=0000000080050033 CR3=000000007cfd8000 CR4=00000000000026f0 > >>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290 > >>>>> (XEN) Host PAT = 0x0000000000000000 > >>>>> (XEN) *** Control State *** > >>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 > >>>>> (XEN) EntryControls=000011ff ExitControls=0003efff > >>>>> (XEN) ExceptionBitmap=00044080 > >>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac ilen=00000000 > >>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 > >>>>> (XEN) reason=80000021 qualification=00000000 > >>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 > >>>>> (XEN) TPR Threshold = 0x00 > >>>>> (XEN) EPT pointer = 0x0000000000000000 > >>>>> (XEN) Virtual processor ID = 0x0000 > >>>>> (XEN) ************************************** > >>>>> (XEN) domain_crash called from vmx.c:2218 > >>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > >>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- > >>>>> (XEN) CPU: 1 > >>>>> (XEN) RIP: 0060:[<000000000000002a>] > >>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > >>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: > >>>>> 0000000000000000 > >>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: > >>>>> 0000000000000000 > >>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: > >>>>> 0000000000000000 > >>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > >>>>> 0000000000000000 > >>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > >>>>> 0000000000000000 > >>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: > >>>>> 0000000000000000 > >>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > >>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 cs: 0060 > >>>>> > >>>>> > >>>>> Any ideas? > >>>>> > >>>>> Tom > >>>>> > >>>>> > >>>>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >>>>>> That should do it. > >>>>>> > >>>>>> K. > >>>>>> > >>>>>> > >>>>>> On 22/04/2009 15:04, "Tom Rotenberg" <tom.rotenberg@gmail.com> > wrote: > >>>>>> > >>>>>>> Keir, > >>>>>>> Just to make sure, i am using the following patch, in order to > disable > >>>>>>> the > >>>>>>> vm86 acceleration: > >>>>>>> > >>>>>>> diff -r cdc044f665dc xen/arch/x86/hvm/vmx/vmx.c > >>>>>>> --- a/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 11:26:37 2009 +0100 > >>>>>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 17:03:20 2009 +0300 > >>>>>>> @@ -829,7 +829,7 @@ > >>>>>>> > >>>>>>> if ( seg == x86_seg_tr ) > >>>>>>> { > >>>>>>> - if ( > v->domain->arch.hvm_domain.params[HVM_PARAM_VM86_TSS] > >>>>>>> ) > >>>>>>> + if (0) > >>>>>>> { > >>>>>>> sel = 0; > >>>>>>> attr = vm86_tr_attr; > >>>>>>> > >>>>>>> Is this OK? > >>>>>>> > >>>>>>> Tom > >>>>>>> > >>>>>>> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com> > >>>>>>>> Yes, the safest way to be sure is probably to replace the if() > >>>>>>>> statement > >>>>>>>> in > >>>>>>>> vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with > if(0). > >>>>>>>> That > >>>>>>>> is > >>>>>>>> the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can > >>>>>>>> re-build/install Xen and be sure that vm86 accel must be disabled. > >>>>>>>> > >>>>>>>> -- Keir > >>>>>>>> > >>>>>>>> On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@gmail.com> > wrote: > >>>>>>>> > >>>>>>>>> So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and > >>>>>>>>> re-check > >>>>>>>>> it? > >>>>>>>>> > >>>>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>>>> At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote: > >>>>>>>>>>> It could be an issue with the vm86 acceleration, possibly. I'm > >>>>>>>>>>> pretty > >>>>>>>>>>> sure > >>>>>>>>>>> the guest would have to IRET from protected mode to enter vm86 > mode > >>>>>>>>>>> itself, > >>>>>>>>>>> and we don't emulate that. Tim: what would we need to do to > disable > >>>>>>>>>>> the > >>>>>>>>>>> vm86 > >>>>>>>>>>> acceleration for testing purposes? You suggested not setting > >>>>>>>>>>> VM86_TSS > >>>>>>>>>>> param > >>>>>>>>>>> from hvmloader, but I couldn't convince myself what effect that > >>>>>>>>>>> would > >>>>>>>>>>> actually have as the logic in Xen is non-trivial. > >>>>>>>>>> > >>>>>>>>>> Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() > will > >>>>>>>>>> always set the tss bit in the bitmap of segments that aren't > safe to > >>>>>>>>>> enter VM86 with. > >>>>>>>>>> > >>>>>>>>>> Tim. > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- Keir > >>>>>>>>>>> > >>>>>>>>>>> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> > >>>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Tim, > >>>>>>>>>>>> > >>>>>>>>>>>> so what does it mean? could it be that we have a bug in the > real > >>>>>>>>>>>> mode > >>>>>>>>>>>> emulation, which causes the segment state to be invalid (maybe > it's > >>>>>>>>>>>> because > >>>>>>>>>>>> of > >>>>>>>>>>>> a bug in the patch that Keir made for me, which emulated the > LLDT, > >>>>>>>>>>>> and > >>>>>>>>>>>> the > >>>>>>>>>>>> LTR > >>>>>>>>>>>> instructions)? > >>>>>>>>>>>> > >>>>>>>>>>>> Keir suggested to trace back where the problem (segment state) > >>>>>>>>>>>> occured, > >>>>>>>>>>>> and > >>>>>>>>>>>> from there to try and find the bug which caused it. Do u have > any > >>>>>>>>>>>> better > >>>>>>>>>>>> suggestion for solving this? > >>>>>>>>>>>> > >>>>>>>>>>>> Tom > >>>>>>>>>>>> > >>>>>>>>>>>> 2009/4/22 Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>>>>>>> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote: > >>>>>>>>>>>>> Keir, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I have tried your latest patch, and it looks like now it > passes > >>>>>>>>>>>>> the > >>>>>>>>>>>>> emulation problem. However, now the domain crashes with the > >>>>>>>>>>>>> following > >>>>>>>>>>>>> error: > >>>>>>>>>>>>> > >>>>>>>>>>>>> (XEN) HVM1: Booting from 0000:7c00 > >>>>>>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by > invalid > >>>>>>>>>>>>> guest > >>>>>>>>>>>>> state > >>>>>>>>>>>>> (0). > >>>>>>>>>>>>> (XEN) ************* VMCS Area ************** > >>>>>>>>>>>>> (XEN) *** Guest State *** > >>>>>>>>>>>>> (XEN) CR0: actual=0x0000000080010039, > shadow=0x0000000080000019, > >>>>>>>>>>>>> gh_mask=ffffffffffffffff > >>>>>>>>>>>>> (XEN) CR4: actual=0x0000000000002060, > shadow=0x0000000000000000, > >>>>>>>>>>>>> gh_mask=ffffffffffffffff > >>>>>>>>>>>>> (XEN) CR3: actual=0x000000000a213a20, target_count=0 > >>>>>>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 > >>>>>>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 > >>>>>>>>>>>>> (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = > >>>>>>>>>>>>> 0x000000000000002a (0x000000000000002a) > >>>>>>>>>>>>> (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = > >>>>>>>>>>>>> 0x0000000000000400 > >>>>>>>>>>>>> > >>>>>>>>>>>>> Looks like we're trying to VMENTER in virtual 8086 mode but > >>>>>>>>>>>>> without > >>>>>>>>>>>>> tidying up the segment state. That could either be the guest > >>>>>>>>>>>>> entering > >>>>>>>>>>>>> virtual 8086 mode itself or Xen entering vitrual 8086 mode to > >>>>>>>>>>>>> emulate > >>>>>>>>>>>>> real mode, but Xen is always careful to make the segment > state > >>>>>>>>>>>>> agree > >>>>>>>>>>>>> with Intel's rather strict requrements when it does that. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Tim. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> (XEN) Sysenter RSP=0000000000000000 > CS:RIP=0000:0000000000000000 > >>>>>>>>>>>>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff, > >>>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff, > >>>>>>>>>>>>> base=0x000000000020ba62 > >>>>>>>>>>>>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff, > >>>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>>> (XEN) GDTR: limit=0x00001dd8, > >>>>>>>>>>>>> base=0x0000000000200000 > >>>>>>>>>>>>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff, > >>>>>>>>>>>>> base=0x0000000000000000 > >>>>>>>>>>>>> (XEN) IDTR: limit=0x00000188, > >>>>>>>>>>>>> base=0x0000000000201df0 > >>>>>>>>>>>>> (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, > >>>>>>>>>>>>> base=0x0000000000201ff2 > >>>>>>>>>>>>> (XEN) Guest PAT = 0x0000000000000000 > >>>>>>>>>>>>> (XEN) TSC Offset = ffffffe4920110b7 > >>>>>>>>>>>>> (XEN) DebugCtl=0000000000000000 > DebugExceptions=0000000000000000 > >>>>>>>>>>>>> (XEN) Interruptibility=0001 ActivityState=0000 > >>>>>>>>>>>>> (XEN) *** Host State *** > >>>>>>>>>>>>> (XEN) RSP = 0xffff83007e4f7fa0 RIP = 0xffff828c8019aa20 > >>>>>>>>>>>>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 > >>>>>>>>>>>>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > >>>>>>>>>>>>> TRBase=ffff828c802a8b00 > >>>>>>>>>>>>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010 > >>>>>>>>>>>>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 > >>>>>>>>>>>>> CR4=00000000000026f0 > >>>>>>>>>>>>> (XEN) Sysenter RSP=ffff83007e4f7fd0 > CS:RIP=e008:ffff828c801c7290 > >>>>>>>>>>>>> (XEN) Host PAT = 0x0000000000000000 > >>>>>>>>>>>>> (XEN) *** Control State *** > >>>>>>>>>>>>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe > SecondaryExec=00000041 > >>>>>>>>>>>>> (XEN) EntryControls=000011ff ExitControls=0003efff > >>>>>>>>>>>>> (XEN) ExceptionBitmap=00044080 > >>>>>>>>>>>>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac > ilen=00000000 > >>>>>>>>>>>>> (XEN) VMExit: intr_info=00000000 errcode=00008000 > ilen=00000000 > >>>>>>>>>>>>> (XEN) reason=80000021 qualification=00000000 > >>>>>>>>>>>>> (XEN) IDTVectoring: info=00000000 errcode=00000000 > >>>>>>>>>>>>> (XEN) TPR Threshold = 0x00 > >>>>>>>>>>>>> (XEN) EPT pointer = 0x0000000000000000 > >>>>>>>>>>>>> (XEN) Virtual processor ID = 0x0000 > >>>>>>>>>>>>> (XEN) ************************************** > >>>>>>>>>>>>> (XEN) domain_crash called from vmx.c:2218 > >>>>>>>>>>>>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1: > >>>>>>>>>>>>> (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted > ]---- > >>>>>>>>>>>>> (XEN) CPU: 1 > >>>>>>>>>>>>> (XEN) RIP: 0060:[<000000000000002a>] > >>>>>>>>>>>>> (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest > >>>>>>>>>>>>> (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: > >>>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>>> (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: > >>>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>>> (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: > >>>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>>> (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: > >>>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>>> (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: > >>>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>>> (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: > >>>>>>>>>>>>> 0000000000000000 > >>>>>>>>>>>>> (XEN) cr3: 0000000001443000 cr2: 0000000000000000 > >>>>>>>>>>>>> (XEN) ds: 0068 es: 0068 fs: 0068 gs: 0068 ss: 0070 > cs: > >>>>>>>>>>>>> 0060 > >>>>>>>>>>>>> > >>>>>>>>>>>>> Could it be, that the real mode emulation code has a bug? > What > >>>>>>>>>>>>> does > >>>>>>>>>>>>> this > >>>>>>>>>>>>> error means? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Tom > >>>>>>>>>>>>> > >>>>>>>>>>>>> 2009/4/22 Keir Fraser > >>>>>>>>>>>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com > >> > >>>>>>>>>>>>> On 22/04/2009 12:18, "Tom Rotenberg" > >>>>>>>>>>>>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> > wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Keir, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I have applied your patch, and it seemed to work. However, > the > >>>>>>>>>>>>> domain > >>>>>>>>>>>>> still > >>>>>>>>>>>>> crashes, and now it looks like it's because of the 'LTR' > >>>>>>>>>>>>> instruction. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Try the attached patch. It replaces the one I sent last time, > and > >>>>>>>>>>>>> emulates > >>>>>>>>>>>>> both LLDT and LTR. > >>>>>>>>>>>>> > >>>>>>>>>>>>> -- Keir > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Content-Description: ATT00001.txt > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> Xen-devel mailing list > >>>>>>>>>>>>> Xen-devel@lists.xensource.com > >>>>>>>>>>>>> http://lists.xensource.com/xen-devel > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> -- > >>>>>>>>>>>>> Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >>>>>>>>>>>>> [Company #02300071, SL9 0DZ, UK.] > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Tim Deegan <Tim.Deegan@citrix.com> > >>>>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >>>>>>>>>> [Company #02300071, SL9 0DZ, UK.] > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > > > > > [-- Attachment #1.2: Type: text/html, Size: 32481 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 11:44 ` Tom Rotenberg @ 2009-04-23 12:15 ` Keir Fraser 2009-04-23 14:08 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-23 12:15 UTC (permalink / raw) To: Tom Rotenberg; +Cc: Tim Deegan, xen-devel@lists.xensource.com On 23/04/2009 12:44, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > However, from the VMCS dump, i saw data, which doesn't seem compatible with > this, as the LDTR sellector is indeed 0, but has attributes and limit > different from zero (although it should have been totaly disabled, by the > LLDT, no?). The 'unused' flag in the attributes word is set (bit 16) so LDTR is okay. > And more important, the TR selector is 0x58, although from the LTR, it was > supposed to be 0x50, no? If 0x50 was loaded then the selector should certainly be 0x50. -- Keir > (of-course it's possible that there were other instructions who changed it > back, however, i am wondering if there is a problem here). ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 12:15 ` Keir Fraser @ 2009-04-23 14:08 ` Tom Rotenberg 2009-04-23 14:28 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-23 14:08 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 1461 bytes --] About the TR, i have re-checked it, and it seems like the TR value is still 0x58, althoug the LTR operation put 0x50 into it. Since, i looked at the LTR code you sent me, and it seems ok, i tend to suspect, that there was some kind of (hardware) task switch, which changed the TR value without me knowing, is it possible? because otherwise, i can't really explain why the TR value is different than what was loaded from the LTR operation... BTW - how can i track what was the previous VMEXIT before this last VMENTRY which caused the exception? i think, that probably the last VMEXIT caused the "change" to vm86 mode, and this is waht causes the problem... Tom 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com> > On 23/04/2009 12:44, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > However, from the VMCS dump, i saw data, which doesn't seem compatible > with > > this, as the LDTR sellector is indeed 0, but has attributes and limit > > different from zero (although it should have been totaly disabled, by the > > LLDT, no?). > > The 'unused' flag in the attributes word is set (bit 16) so LDTR is okay. > > > And more important, the TR selector is 0x58, although from the LTR, it > was > > supposed to be 0x50, no? > > If 0x50 was loaded then the selector should certainly be 0x50. > > -- Keir > > > (of-course it's possible that there were other instructions who changed > it > > back, however, i am wondering if there is a problem here). > > > [-- Attachment #1.2: Type: text/html, Size: 2052 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 14:08 ` Tom Rotenberg @ 2009-04-23 14:28 ` Keir Fraser 2009-04-23 15:57 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-23 14:28 UTC (permalink / raw) To: Tom Rotenberg; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 1968 bytes --] All task switches are emulated, so you can add tracing to hvm_task_switch() to check if a switch has occurred. An alternative is that the guest did another LTR while not being emulated? If you want to remember the last VMEXIT, you¹ll have to add code to store state away somewhere to pick up on the next VMENTRY. -- Keir On 23/04/2009 15:08, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > About the TR, i have re-checked it, and it seems like the TR value is still > 0x58, althoug the LTR operation put 0x50 into it. Since, i looked at the LTR > code you sent me, and it seems ok, i tend to suspect, that there was some kind > of (hardware) task switch, which changed the TR value without me knowing, is > it possible? because otherwise, i can't really explain why the TR value is > different than what was loaded from the LTR operation... > > BTW - how can i track what was the previous VMEXIT before this last VMENTRY > which caused the exception? i think, that probably the last VMEXIT caused the > "change" to vm86 mode, and this is waht causes the problem... > > Tom > > 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com> >> On 23/04/2009 12:44, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >> >>> > However, from the VMCS dump, i saw data, which doesn't seem compatible >>> with >>> > this, as the LDTR sellector is indeed 0, but has attributes and limit >>> > different from zero (although it should have been totaly disabled, by the >>> > LLDT, no?). >> >> The 'unused' flag in the attributes word is set (bit 16) so LDTR is okay. >> >>> > And more important, the TR selector is 0x58, although from the LTR, it was >>> > supposed to be 0x50, no? >> >> If 0x50 was loaded then the selector should certainly be 0x50. >> >> -- Keir >> >>> > (of-course it's possible that there were other instructions who changed it >>> > back, however, i am wondering if there is a problem here). >> >> > [-- Attachment #1.2: Type: text/html, Size: 2805 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 14:28 ` Keir Fraser @ 2009-04-23 15:57 ` Tom Rotenberg 2009-04-23 16:01 ` Tim Deegan 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-23 15:57 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 2372 bytes --] Keir, After further testing, it seems like the flow of events were like this: there was a VMEXIT with the reason of task switch, which changed to vm86mode (!), and upon trying to resume from this vmexit, the cpu raised an exception. And the question is why and how did the task switch caused the vm86 mode to be turned on? is it even legal? Tom 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com> > All task switches are emulated, so you can add tracing to > hvm_task_switch() to check if a switch has occurred. An alternative is that > the guest did another LTR while not being emulated? > > If you want to remember the last VMEXIT, you’ll have to add code to store > state away somewhere to pick up on the next VMENTRY. > > -- Keir > > > On 23/04/2009 15:08, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > About the TR, i have re-checked it, and it seems like the TR value is still > 0x58, althoug the LTR operation put 0x50 into it. Since, i looked at the LTR > code you sent me, and it seems ok, i tend to suspect, that there was some > kind of (hardware) task switch, which changed the TR value without me > knowing, is it possible? because otherwise, i can't really explain why the > TR value is different than what was loaded from the LTR operation... > > BTW - how can i track what was the previous VMEXIT before this last VMENTRY > which caused the exception? i think, that probably the last VMEXIT caused > the "change" to vm86 mode, and this is waht causes the problem... > > Tom > > 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com> > > On 23/04/2009 12:44, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > However, from the VMCS dump, i saw data, which doesn't seem compatible > with > > this, as the LDTR sellector is indeed 0, but has attributes and limit > > different from zero (although it should have been totaly disabled, by the > > LLDT, no?). > > The 'unused' flag in the attributes word is set (bit 16) so LDTR is okay. > > > And more important, the TR selector is 0x58, although from the LTR, it > was > > supposed to be 0x50, no? > > If 0x50 was loaded then the selector should certainly be 0x50. > > -- Keir > > > (of-course it's possible that there were other instructions who changed > it > > back, however, i am wondering if there is a problem here). > > > > [-- Attachment #1.2: Type: text/html, Size: 3582 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 15:57 ` Tom Rotenberg @ 2009-04-23 16:01 ` Tim Deegan 2009-04-23 16:10 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Tim Deegan @ 2009-04-23 16:01 UTC (permalink / raw) To: Tom Rotenberg; +Cc: xen-devel@lists.xensource.com, Keir Fraser At 16:57 +0100 on 23 Apr (1240505849), Tom Rotenberg wrote: > Keir, > > After further testing, it seems like the flow of events were like this: there was a VMEXIT with the reason of task switch, which changed to vm86mode (!), and upon trying to resume from this vmexit, the cpu raised an exception. > > And the question is why and how did the task switch caused the vm86 > mode to be turned on? is it even legal? Yes, task-switching into vm86 mode is legal; ISTR it and IRET are the only ways mentioned in the SDMs of getting into vm86. Looks like Xen doesn't support it, though. It would need special handling of the segment state to get round the extra restrictions that Intel imposed on VMENTER (which are stricter than the limits on using vm86 mode unvirtualized). Cheers, Tim. > Tom > > 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> > All task switches are emulated, so you can add tracing to hvm_task_switch() to check if a switch has occurred. An alternative is that the guest did another LTR while not being emulated? > > If you want to remember the last VMEXIT, you?ll have to add code to store state away somewhere to pick up on the next VMENTRY. > > -- Keir > > > On 23/04/2009 15:08, "Tom Rotenberg" <tom.rotenberg@gmail.com<http://tom.rotenberg@gmail.com>> wrote: > > About the TR, i have re-checked it, and it seems like the TR value is still 0x58, althoug the LTR operation put 0x50 into it. Since, i looked at the LTR code you sent me, and it seems ok, i tend to suspect, that there was some kind of (hardware) task switch, which changed the TR value without me knowing, is it possible? because otherwise, i can't really explain why the TR value is different than what was loaded from the LTR operation... > > BTW - how can i track what was the previous VMEXIT before this last VMENTRY which caused the exception? i think, that probably the last VMEXIT caused the "change" to vm86 mode, and this is waht causes the problem... > > Tom > > 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com<http://keir.fraser@eu.citrix.com>> > On 23/04/2009 12:44, "Tom Rotenberg" <tom.rotenberg@gmail.com<http://tom.rotenberg@gmail.com>> wrote: > > > However, from the VMCS dump, i saw data, which doesn't seem compatible with > > this, as the LDTR sellector is indeed 0, but has attributes and limit > > different from zero (although it should have been totaly disabled, by the > > LLDT, no?). > > The 'unused' flag in the attributes word is set (bit 16) so LDTR is okay. > > > And more important, the TR selector is 0x58, although from the LTR, it was > > supposed to be 0x50, no? > > If 0x50 was loaded then the selector should certainly be 0x50. > > -- Keir > > > (of-course it's possible that there were other instructions who changed it > > back, however, i am wondering if there is a problem here). > > > -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 16:01 ` Tim Deegan @ 2009-04-23 16:10 ` Tom Rotenberg 2009-04-23 17:16 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-23 16:10 UTC (permalink / raw) To: Tim Deegan; +Cc: xen-devel@lists.xensource.com, Keir Fraser [-- Attachment #1.1: Type: text/plain, Size: 3261 bytes --] So, do u have any suggestion, on how can i fix this issue? 2009/4/23 Tim Deegan <Tim.Deegan@citrix.com> > At 16:57 +0100 on 23 Apr (1240505849), Tom Rotenberg wrote: > > Keir, > > > > After further testing, it seems like the flow of events were like this: > there was a VMEXIT with the reason of task switch, which changed to vm86mode > (!), and upon trying to resume from this vmexit, the cpu raised an > exception. > > > > And the question is why and how did the task switch caused the vm86 > > mode to be turned on? is it even legal? > > Yes, task-switching into vm86 mode is legal; ISTR it and IRET are the > only ways mentioned in the SDMs of getting into vm86. > > Looks like Xen doesn't support it, though. It would need special > handling of the segment state to get round the extra restrictions that > Intel imposed on VMENTER (which are stricter than the limits on using > vm86 mode unvirtualized). > > Cheers, > > Tim. > > > Tom > > > > 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com<mailto: > keir.fraser@eu.citrix.com>> > > All task switches are emulated, so you can add tracing to > hvm_task_switch() to check if a switch has occurred. An alternative is that > the guest did another LTR while not being emulated? > > > > If you want to remember the last VMEXIT, you?ll have to add code to store > state away somewhere to pick up on the next VMENTRY. > > > > -- Keir > > > > > > On 23/04/2009 15:08, "Tom Rotenberg" <tom.rotenberg@gmail.com< > http://tom.rotenberg@gmail.com>> wrote: > > > > About the TR, i have re-checked it, and it seems like the TR value is > still 0x58, althoug the LTR operation put 0x50 into it. Since, i looked at > the LTR code you sent me, and it seems ok, i tend to suspect, that there was > some kind of (hardware) task switch, which changed the TR value without me > knowing, is it possible? because otherwise, i can't really explain why the > TR value is different than what was loaded from the LTR operation... > > > > BTW - how can i track what was the previous VMEXIT before this last > VMENTRY which caused the exception? i think, that probably the last VMEXIT > caused the "change" to vm86 mode, and this is waht causes the problem... > > > > Tom > > > > 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com<http://keir.fraser@ > eu.citrix.com>> > > On 23/04/2009 12:44, "Tom Rotenberg" <tom.rotenberg@gmail.com< > http://tom.rotenberg@gmail.com>> wrote: > > > > > However, from the VMCS dump, i saw data, which doesn't seem compatible > with > > > this, as the LDTR sellector is indeed 0, but has attributes and limit > > > different from zero (although it should have been totaly disabled, by > the > > > LLDT, no?). > > > > The 'unused' flag in the attributes word is set (bit 16) so LDTR is okay. > > > > > And more important, the TR selector is 0x58, although from the LTR, it > was > > > supposed to be 0x50, no? > > > > If 0x50 was loaded then the selector should certainly be 0x50. > > > > -- Keir > > > > > (of-course it's possible that there were other instructions who changed > it > > > back, however, i am wondering if there is a problem here). > > > > > > > > -- > Tim Deegan <Tim.Deegan@citrix.com> > Principal Software Engineer, Citrix Systems (R&D) Ltd. > [Company #02300071, SL9 0DZ, UK.] > [-- Attachment #1.2: Type: text/html, Size: 4680 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 16:10 ` Tom Rotenberg @ 2009-04-23 17:16 ` Keir Fraser 2009-04-23 17:27 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-23 17:16 UTC (permalink / raw) To: Tom Rotenberg, Tim Deegan; +Cc: xen-devel@lists.xensource.com A task switch reloads on segment registers, so it is impossible to enter vm86 mode with 'bad' segment state even via a task switch. If the guest really is trying to enter vm86 mode via a task switch (which would be somewhat bizarre, although a valid thing to do) then hvm_load_segment_selector() needs updating to deal with VM86 mode. I'll make a patch. -- Keir On 23/04/2009 17:10, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > So, do u have any suggestion, on how can i fix this issue? > > 2009/4/23 Tim Deegan <Tim.Deegan@citrix.com> >> At 16:57 +0100 on 23 Apr (1240505849), Tom Rotenberg wrote: >>> Keir, >>> >>> After further testing, it seems like the flow of events were like this: >>> there was a VMEXIT with the reason of task switch, which changed to vm86mode >>> (!), and upon trying to resume from this vmexit, the cpu raised an >>> exception. >>> >>> And the question is why and how did the task switch caused the vm86 >>> mode to be turned on? is it even legal? >> >> Yes, task-switching into vm86 mode is legal; ISTR it and IRET are the >> only ways mentioned in the SDMs of getting into vm86. >> >> Looks like Xen doesn't support it, though. It would need special >> handling of the segment state to get round the extra restrictions that >> Intel imposed on VMENTER (which are stricter than the limits on using >> vm86 mode unvirtualized). >> >> Cheers, >> >> Tim. >> >>> Tom >>> >>> 2009/4/23 Keir Fraser >>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> >>> All task switches are emulated, so you can add tracing to hvm_task_switch() >>> to check if a switch has occurred. An alternative is that the guest did >>> another LTR while not being emulated? >>> >>> If you want to remember the last VMEXIT, you?ll have to add code to store >>> state away somewhere to pick up on the next VMENTRY. >>> >>> -- Keir >>> >>> >>> On 23/04/2009 15:08, "Tom Rotenberg" >>> <tom.rotenberg@gmail.com<http://tom.rotenberg@gmail.com <http://gmail.com> >>> >> wrote: >>> >>> About the TR, i have re-checked it, and it seems like the TR value is still >>> 0x58, althoug the LTR operation put 0x50 into it. Since, i looked at the LTR >>> code you sent me, and it seems ok, i tend to suspect, that there was some >>> kind of (hardware) task switch, which changed the TR value without me >>> knowing, is it possible? because otherwise, i can't really explain why the >>> TR value is different than what was loaded from the LTR operation... >>> >>> BTW - how can i track what was the previous VMEXIT before this last VMENTRY >>> which caused the exception? i think, that probably the last VMEXIT caused >>> the "change" to vm86 mode, and this is waht causes the problem... >>> >>> Tom >>> >>> 2009/4/23 Keir Fraser >>> <keir.fraser@eu.citrix.com<http://keir.fraser@eu.citrix.com >>> <http://eu.citrix.com> >> >>> On 23/04/2009 12:44, "Tom Rotenberg" >>> <tom.rotenberg@gmail.com<http://tom.rotenberg@gmail.com <http://gmail.com> >>> >> wrote: >>> >>>> However, from the VMCS dump, i saw data, which doesn't seem compatible with >>>> this, as the LDTR sellector is indeed 0, but has attributes and limit >>>> different from zero (although it should have been totaly disabled, by the >>>> LLDT, no?). >>> >>> The 'unused' flag in the attributes word is set (bit 16) so LDTR is okay. >>> >>>> And more important, the TR selector is 0x58, although from the LTR, it was >>>> supposed to be 0x50, no? >>> >>> If 0x50 was loaded then the selector should certainly be 0x50. >>> >>> -- Keir >>> >>>> (of-course it's possible that there were other instructions who changed it >>>> back, however, i am wondering if there is a problem here). >>> >>> >>> >> >> -- >> Tim Deegan <Tim.Deegan@citrix.com> >> Principal Software Engineer, Citrix Systems (R&D) Ltd. >> [Company #02300071, SL9 0DZ, UK.] > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 17:16 ` Keir Fraser @ 2009-04-23 17:27 ` Keir Fraser 2009-04-23 17:38 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-23 17:27 UTC (permalink / raw) To: Tom Rotenberg, Tim Deegan; +Cc: xen-devel@lists.xensource.com [-- Attachment #1: Type: text/plain, Size: 4224 bytes --] Patch is attached. It is in addition to the LTR/LLDT patch. -- Keir On 23/04/2009 18:16, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: > A task switch reloads on segment registers, so it is impossible to enter > vm86 mode with 'bad' segment state even via a task switch. > > If the guest really is trying to enter vm86 mode via a task switch (which > would be somewhat bizarre, although a valid thing to do) then > hvm_load_segment_selector() needs updating to deal with VM86 mode. I'll make > a patch. > > -- Keir > > On 23/04/2009 17:10, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > >> So, do u have any suggestion, on how can i fix this issue? >> >> 2009/4/23 Tim Deegan <Tim.Deegan@citrix.com> >>> At 16:57 +0100 on 23 Apr (1240505849), Tom Rotenberg wrote: >>>> Keir, >>>> >>>> After further testing, it seems like the flow of events were like this: >>>> there was a VMEXIT with the reason of task switch, which changed to >>>> vm86mode >>>> (!), and upon trying to resume from this vmexit, the cpu raised an >>>> exception. >>>> >>>> And the question is why and how did the task switch caused the vm86 >>>> mode to be turned on? is it even legal? >>> >>> Yes, task-switching into vm86 mode is legal; ISTR it and IRET are the >>> only ways mentioned in the SDMs of getting into vm86. >>> >>> Looks like Xen doesn't support it, though. It would need special >>> handling of the segment state to get round the extra restrictions that >>> Intel imposed on VMENTER (which are stricter than the limits on using >>> vm86 mode unvirtualized). >>> >>> Cheers, >>> >>> Tim. >>> >>>> Tom >>>> >>>> 2009/4/23 Keir Fraser >>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> >>>> All task switches are emulated, so you can add tracing to hvm_task_switch() >>>> to check if a switch has occurred. An alternative is that the guest did >>>> another LTR while not being emulated? >>>> >>>> If you want to remember the last VMEXIT, you?ll have to add code to store >>>> state away somewhere to pick up on the next VMENTRY. >>>> >>>> -- Keir >>>> >>>> >>>> On 23/04/2009 15:08, "Tom Rotenberg" >>>> <tom.rotenberg@gmail.com<http://tom.rotenberg@gmail.com <http://gmail.com> >>>>>> wrote: >>>> >>>> About the TR, i have re-checked it, and it seems like the TR value is still >>>> 0x58, althoug the LTR operation put 0x50 into it. Since, i looked at the >>>> LTR >>>> code you sent me, and it seems ok, i tend to suspect, that there was some >>>> kind of (hardware) task switch, which changed the TR value without me >>>> knowing, is it possible? because otherwise, i can't really explain why the >>>> TR value is different than what was loaded from the LTR operation... >>>> >>>> BTW - how can i track what was the previous VMEXIT before this last VMENTRY >>>> which caused the exception? i think, that probably the last VMEXIT caused >>>> the "change" to vm86 mode, and this is waht causes the problem... >>>> >>>> Tom >>>> >>>> 2009/4/23 Keir Fraser >>>> <keir.fraser@eu.citrix.com<http://keir.fraser@eu.citrix.com >>>> <http://eu.citrix.com> >> >>>> On 23/04/2009 12:44, "Tom Rotenberg" >>>> <tom.rotenberg@gmail.com<http://tom.rotenberg@gmail.com <http://gmail.com> >>>>>> wrote: >>>> >>>>> However, from the VMCS dump, i saw data, which doesn't seem compatible >>>>> with >>>>> this, as the LDTR sellector is indeed 0, but has attributes and limit >>>>> different from zero (although it should have been totaly disabled, by the >>>>> LLDT, no?). >>>> >>>> The 'unused' flag in the attributes word is set (bit 16) so LDTR is okay. >>>> >>>>> And more important, the TR selector is 0x58, although from the LTR, it was >>>>> supposed to be 0x50, no? >>>> >>>> If 0x50 was loaded then the selector should certainly be 0x50. >>>> >>>> -- Keir >>>> >>>>> (of-course it's possible that there were other instructions who changed it >>>>> back, however, i am wondering if there is a problem here). >>>> >>>> >>>> >>> >>> -- >>> Tim Deegan <Tim.Deegan@citrix.com> >>> Principal Software Engineer, Citrix Systems (R&D) Ltd. >>> [Company #02300071, SL9 0DZ, UK.] >> > [-- Attachment #2: 00-vm86_tswitch --] [-- Type: application/octet-stream, Size: 1844 bytes --] diff -r 8b152638adaa xen/arch/x86/hvm/hvm.c --- a/xen/arch/x86/hvm/hvm.c Thu Apr 23 16:22:48 2009 +0100 +++ b/xen/arch/x86/hvm/hvm.c Thu Apr 23 18:25:49 2009 +0100 @@ -1188,12 +1188,24 @@ } static int hvm_load_segment_selector( - struct vcpu *v, enum x86_segment seg, uint16_t sel) + enum x86_segment seg, uint16_t sel) { struct segment_register desctab, cs, segr; struct desc_struct *pdesc, desc; u8 dpl, rpl, cpl; int fault_type = TRAP_invalid_tss; + struct cpu_user_regs *regs = guest_cpu_user_regs(); + struct vcpu *v = current; + + if ( regs->eflags & EF_VM ) + { + segr.sel = sel; + segr.base = (uint32_t)sel << 4; + segr.limit = 0xffffu; + segr.attr.bytes = 0xf3; + hvm_set_segment_register(v, seg, &segr); + return 0; + } /* NULL selector? */ if ( (sel & 0xfffc) == 0 ) @@ -1440,13 +1452,13 @@ } exn_raised = 0; - if ( hvm_load_segment_selector(v, x86_seg_es, tss.es) || - hvm_load_segment_selector(v, x86_seg_cs, tss.cs) || - hvm_load_segment_selector(v, x86_seg_ss, tss.ss) || - hvm_load_segment_selector(v, x86_seg_ds, tss.ds) || - hvm_load_segment_selector(v, x86_seg_fs, tss.fs) || - hvm_load_segment_selector(v, x86_seg_gs, tss.gs) || - hvm_load_segment_selector(v, x86_seg_ldtr, tss.ldt) ) + if ( hvm_load_segment_selector(x86_seg_es, tss.es) || + hvm_load_segment_selector(x86_seg_cs, tss.cs) || + hvm_load_segment_selector(x86_seg_ss, tss.ss) || + hvm_load_segment_selector(x86_seg_ds, tss.ds) || + hvm_load_segment_selector(x86_seg_fs, tss.fs) || + hvm_load_segment_selector(x86_seg_gs, tss.gs) || + hvm_load_segment_selector(x86_seg_ldtr, tss.ldt) ) exn_raised = 1; rc = hvm_copy_to_guest_virt( [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 17:27 ` Keir Fraser @ 2009-04-23 17:38 ` Tom Rotenberg 2009-04-23 17:49 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-23 17:38 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 8156 bytes --] Keir, I applied the patch, and it seems it helped a little, however, the domain is still crashing, with the following error: (XEN) HVM1: Booting from 0000:7c00 (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state (0). (XEN) ************* VMCS Area ************** (XEN) *** Guest State *** (XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, gh_mask=ffffffffffffffff (XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, gh_mask=ffffffffffffffff (XEN) CR3: actual=0x000000000a211a20, target_count=0 (XEN) target0=0000000000000000, target1=0000000000000000 (XEN) target2=0000000000000000, target3=0000000000000000 (XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = 0x000000000000002a (0x000000000000002a) (XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = 0x0000000000000400 (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 (XEN) CS: sel=0x14a2, attr=0x000f3, limit=0x0000ffff, base=0x0000000000014a20 (XEN) DS: sel=0x1da8, attr=0x000f3, limit=0x0000ffff, base=0x000000000001da80 (XEN) SS: sel=0x1ea6, attr=0x000f3, limit=0x0000ffff, base=0x000000000001ea60 (XEN) ES: sel=0x1eae, attr=0x000f3, limit=0x0000ffff, base=0x000000000001eae0 (XEN) FS: sel=0x0000, attr=0x000f3, limit=0x0000ffff, base=0x0000000000000000 (XEN) GS: sel=0x0000, attr=0x000f3, limit=0x0000ffff, base=0x0000000000000000 (XEN) GDTR: limit=0x00001dd8, base=0x0000000000200000 (XEN) LDTR: sel=0x0000, attr=0x000f3, limit=0x0000ffff, base=0x0000000000000000 (XEN) IDTR: limit=0x00000188, base=0x0000000000201df0 (XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, base=0x0000000000201ff2 (XEN) Guest PAT = 0x0000000000000000 (XEN) TSC Offset = ffffffcaa41ccde0 (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 (XEN) Interruptibility=0001 ActivityState=0000 (XEN) *** Host State *** (XEN) RSP = 0xffff828c8026ffa0 RIP = 0xffff828c8019aa90 (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 (XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff828c802a8a80 (XEN) GDTBase=ffff828c800f3000 IDTBase=ffff828c802ac420 (XEN) CR0=0000000080050033 CR3=000000007cfd4000 CR4=00000000000026f0 (XEN) Sysenter RSP=ffff828c8026ffd0 CS:RIP=e008:ffff828c801c7290 (XEN) Host PAT = 0x0000000000000000 (XEN) *** Control State *** (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041 (XEN) EntryControls=000011ff ExitControls=0003efff (XEN) ExceptionBitmap=00044080 (XEN) VMEntry: intr_info=00000000 errcode=00000000 ilen=00000000 (XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000 (XEN) reason=80000021 qualification=00000000 (XEN) IDTVectoring: info=00000000 errcode=00000000 (XEN) TPR Threshold = 0x00 (XEN) EPT pointer = 0x0000000000000000 (XEN) Virtual processor ID = 0x0000 (XEN) ************************************** (XEN) domain_crash called from vmx.c:2218 (XEN) Domain 1 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: 14a2:[<000000000000002a>] (XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest (XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: 0000000000000000 (XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: 0000000000000000 (XEN) cr3: 0000000001443000 cr2: 0000000000000000 (XEN) ds: 1da8 es: 1eae fs: 0000 gs: 0000 ss: 1ea6 cs: 14a2 Any ideas to what is wrong now? Tom 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com> > Patch is attached. It is in addition to the LTR/LLDT patch. > > -- Keir > > On 23/04/2009 18:16, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote: > > > A task switch reloads on segment registers, so it is impossible to enter > > vm86 mode with 'bad' segment state even via a task switch. > > > > If the guest really is trying to enter vm86 mode via a task switch (which > > would be somewhat bizarre, although a valid thing to do) then > > hvm_load_segment_selector() needs updating to deal with VM86 mode. I'll > make > > a patch. > > > > -- Keir > > > > On 23/04/2009 17:10, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > >> So, do u have any suggestion, on how can i fix this issue? > >> > >> 2009/4/23 Tim Deegan <Tim.Deegan@citrix.com> > >>> At 16:57 +0100 on 23 Apr (1240505849), Tom Rotenberg wrote: > >>>> Keir, > >>>> > >>>> After further testing, it seems like the flow of events were like > this: > >>>> there was a VMEXIT with the reason of task switch, which changed to > >>>> vm86mode > >>>> (!), and upon trying to resume from this vmexit, the cpu raised an > >>>> exception. > >>>> > >>>> And the question is why and how did the task switch caused the vm86 > >>>> mode to be turned on? is it even legal? > >>> > >>> Yes, task-switching into vm86 mode is legal; ISTR it and IRET are the > >>> only ways mentioned in the SDMs of getting into vm86. > >>> > >>> Looks like Xen doesn't support it, though. It would need special > >>> handling of the segment state to get round the extra restrictions that > >>> Intel imposed on VMENTER (which are stricter than the limits on using > >>> vm86 mode unvirtualized). > >>> > >>> Cheers, > >>> > >>> Tim. > >>> > >>>> Tom > >>>> > >>>> 2009/4/23 Keir Fraser > >>>> <keir.fraser@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>> > >>>> All task switches are emulated, so you can add tracing to > hvm_task_switch() > >>>> to check if a switch has occurred. An alternative is that the guest > did > >>>> another LTR while not being emulated? > >>>> > >>>> If you want to remember the last VMEXIT, you?ll have to add code to > store > >>>> state away somewhere to pick up on the next VMENTRY. > >>>> > >>>> -- Keir > >>>> > >>>> > >>>> On 23/04/2009 15:08, "Tom Rotenberg" > >>>> <tom.rotenberg@gmail.com<http://tom.rotenberg@gmail.com < > http://gmail.com> > >>>>>> wrote: > >>>> > >>>> About the TR, i have re-checked it, and it seems like the TR value is > still > >>>> 0x58, althoug the LTR operation put 0x50 into it. Since, i looked at > the > >>>> LTR > >>>> code you sent me, and it seems ok, i tend to suspect, that there was > some > >>>> kind of (hardware) task switch, which changed the TR value without me > >>>> knowing, is it possible? because otherwise, i can't really explain why > the > >>>> TR value is different than what was loaded from the LTR operation... > >>>> > >>>> BTW - how can i track what was the previous VMEXIT before this last > VMENTRY > >>>> which caused the exception? i think, that probably the last VMEXIT > caused > >>>> the "change" to vm86 mode, and this is waht causes the problem... > >>>> > >>>> Tom > >>>> > >>>> 2009/4/23 Keir Fraser > >>>> <keir.fraser@eu.citrix.com<http://keir.fraser@eu.citrix.com > >>>> <http://eu.citrix.com> >> > >>>> On 23/04/2009 12:44, "Tom Rotenberg" > >>>> <tom.rotenberg@gmail.com<http://tom.rotenberg@gmail.com < > http://gmail.com> > >>>>>> wrote: > >>>> > >>>>> However, from the VMCS dump, i saw data, which doesn't seem > compatible > >>>>> with > >>>>> this, as the LDTR sellector is indeed 0, but has attributes and limit > >>>>> different from zero (although it should have been totaly disabled, by > the > >>>>> LLDT, no?). > >>>> > >>>> The 'unused' flag in the attributes word is set (bit 16) so LDTR is > okay. > >>>> > >>>>> And more important, the TR selector is 0x58, although from the LTR, > it was > >>>>> supposed to be 0x50, no? > >>>> > >>>> If 0x50 was loaded then the selector should certainly be 0x50. > >>>> > >>>> -- Keir > >>>> > >>>>> (of-course it's possible that there were other instructions who > changed it > >>>>> back, however, i am wondering if there is a problem here). > >>>> > >>>> > >>>> > >>> > >>> -- > >>> Tim Deegan <Tim.Deegan@citrix.com> > >>> Principal Software Engineer, Citrix Systems (R&D) Ltd. > >>> [Company #02300071, SL9 0DZ, UK.] > >> > > > > [-- Attachment #1.2: Type: text/html, Size: 11181 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 17:38 ` Tom Rotenberg @ 2009-04-23 17:49 ` Keir Fraser 2009-04-23 18:00 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-23 17:49 UTC (permalink / raw) To: Tom Rotenberg; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1: Type: text/plain, Size: 276 bytes --] On 23/04/2009 18:38, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > Keir, > > I applied the patch, and it seems it helped a little, however, the domain is > still crashing, with the following error: Ah, the patch had a bug. Try the attached updated version. -- Keir [-- Attachment #2: 00-vm86_tswitch --] [-- Type: application/octet-stream, Size: 2398 bytes --] diff -r 8b152638adaa xen/arch/x86/hvm/hvm.c --- a/xen/arch/x86/hvm/hvm.c Thu Apr 23 16:22:48 2009 +0100 +++ b/xen/arch/x86/hvm/hvm.c Thu Apr 23 18:47:17 2009 +0100 @@ -1188,12 +1188,24 @@ } static int hvm_load_segment_selector( - struct vcpu *v, enum x86_segment seg, uint16_t sel) + enum x86_segment seg, uint16_t sel) { struct segment_register desctab, cs, segr; struct desc_struct *pdesc, desc; u8 dpl, rpl, cpl; int fault_type = TRAP_invalid_tss; + struct cpu_user_regs *regs = guest_cpu_user_regs(); + struct vcpu *v = current; + + if ( (regs->eflags & EF_VM) && is_x86_user_segment(seg) ) + { + segr.sel = sel; + segr.base = (uint32_t)sel << 4; + segr.limit = 0xffffu; + segr.attr.bytes = 0xf3; + hvm_set_segment_register(v, seg, &segr); + return 0; + } /* NULL selector? */ if ( (sel & 0xfffc) == 0 ) @@ -1440,13 +1452,13 @@ } exn_raised = 0; - if ( hvm_load_segment_selector(v, x86_seg_es, tss.es) || - hvm_load_segment_selector(v, x86_seg_cs, tss.cs) || - hvm_load_segment_selector(v, x86_seg_ss, tss.ss) || - hvm_load_segment_selector(v, x86_seg_ds, tss.ds) || - hvm_load_segment_selector(v, x86_seg_fs, tss.fs) || - hvm_load_segment_selector(v, x86_seg_gs, tss.gs) || - hvm_load_segment_selector(v, x86_seg_ldtr, tss.ldt) ) + if ( hvm_load_segment_selector(x86_seg_es, tss.es) || + hvm_load_segment_selector(x86_seg_cs, tss.cs) || + hvm_load_segment_selector(x86_seg_ss, tss.ss) || + hvm_load_segment_selector(x86_seg_ds, tss.ds) || + hvm_load_segment_selector(x86_seg_fs, tss.fs) || + hvm_load_segment_selector(x86_seg_gs, tss.gs) || + hvm_load_segment_selector(x86_seg_ldtr, tss.ldt) ) exn_raised = 1; rc = hvm_copy_to_guest_virt( diff -r 8b152638adaa xen/arch/x86/x86_emulate/x86_emulate.c --- a/xen/arch/x86/x86_emulate/x86_emulate.c Thu Apr 23 16:22:48 2009 +0100 +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Thu Apr 23 18:47:17 2009 +0100 @@ -1099,7 +1099,7 @@ (ops->write_segment == NULL) ) return X86EMUL_UNHANDLEABLE; - if ( in_protmode(ctxt, ops) ) + if ( in_protmode(ctxt, ops) || !is_x86_user_segment(seg) ) return protmode_load_seg(seg, sel, ctxt, ops); return realmode_load_seg(seg, sel, ctxt, ops); [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 17:49 ` Keir Fraser @ 2009-04-23 18:00 ` Tom Rotenberg 2009-04-23 18:27 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-23 18:00 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 951 bytes --] Keir, I have applied the patch, and it looks like now it passed this part. However, now, it hangs, and doesn't show the PointSec pre-boot GUI. I have also seen the following messages in 'xm dmesg': (XEN) HVM2: Booting from Hard Disk... (XEN) HVM2: Booting from 0000:7c00 (XEN) multi.c:3351:d2 write to pagetable during event injection: cr2=0x2234bc, mfn=0x29c23 (XEN) multi.c:3351:d2 write to pagetable during event injection: cr2=0x1032ff8, mfn=0x28e32 (XEN) multi.c:3351:d2 write to pagetable during event injection: cr2=0x102fff8, mfn=0x28e2f Do u have any idea what may cause this problem? Tom 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com> > On 23/04/2009 18:38, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > Keir, > > > > I applied the patch, and it seems it helped a little, however, the domain > is > > still crashing, with the following error: > > Ah, the patch had a bug. Try the attached updated version. > > -- Keir > > [-- Attachment #1.2: Type: text/html, Size: 1444 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 18:00 ` Tom Rotenberg @ 2009-04-23 18:27 ` Keir Fraser 2009-04-23 20:16 ` Tom Rotenberg 2009-04-26 10:59 ` Tom Rotenberg 0 siblings, 2 replies; 43+ messages in thread From: Keir Fraser @ 2009-04-23 18:27 UTC (permalink / raw) To: Tom Rotenberg; +Cc: Tim Deegan, xen-devel@lists.xensource.com On 23/04/2009 19:00, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > I have applied the patch, and it looks like now it passed this part. However, > now, it hangs, and doesn't show the PointSec pre-boot GUI. I have also seen > the following messages in 'xm dmesg': > > (XEN) HVM2: Booting from Hard Disk... > (XEN) HVM2: Booting from 0000:7c00 > (XEN) multi.c:3351:d2 write to pagetable during event injection: cr2=0x2234bc, > mfn=0x29c23 > (XEN) multi.c:3351:d2 write to pagetable during event injection: > cr2=0x1032ff8, mfn=0x28e32 > (XEN) multi.c:3351:d2 write to pagetable during event injection: > cr2=0x102fff8, mfn=0x28e2f > > Do u have any idea what may cause this problem? Those messages are usually rare and typically indicate that a guest pagetable page has been recycled as a kernel stack page, and is being written to as part of an exception/interrupt delivery. My guess for why you're seeing it is that you've entered some horrible exception loop where the exception handler causes another exception, and this repeats itself. This would cause the stack to overwrite memory (as exception stack frames stack up one on top of the other on top of the other...), taking out pagetable pages as it goes. You'd then hang or crash when enough memory is overwitten that the exception loop gets broken. Since the root cause of the exceptions happened some time back in execution, this could be a pain to debug. :-) And my theory may not even be correct... -- Keir ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 18:27 ` Keir Fraser @ 2009-04-23 20:16 ` Tom Rotenberg 2009-04-26 10:59 ` Tom Rotenberg 1 sibling, 0 replies; 43+ messages in thread From: Tom Rotenberg @ 2009-04-23 20:16 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 1733 bytes --] wow... that's sucks :( Well, let me dive into it, and i will update you when i will understand what is causing this issue. Thanks. 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com> > On 23/04/2009 19:00, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > I have applied the patch, and it looks like now it passed this part. > However, > > now, it hangs, and doesn't show the PointSec pre-boot GUI. I have also > seen > > the following messages in 'xm dmesg': > > > > (XEN) HVM2: Booting from Hard Disk... > > (XEN) HVM2: Booting from 0000:7c00 > > (XEN) multi.c:3351:d2 write to pagetable during event injection: > cr2=0x2234bc, > > mfn=0x29c23 > > (XEN) multi.c:3351:d2 write to pagetable during event injection: > > cr2=0x1032ff8, mfn=0x28e32 > > (XEN) multi.c:3351:d2 write to pagetable during event injection: > > cr2=0x102fff8, mfn=0x28e2f > > > > Do u have any idea what may cause this problem? > > Those messages are usually rare and typically indicate that a guest > pagetable page has been recycled as a kernel stack page, and is being > written to as part of an exception/interrupt delivery. My guess for why > you're seeing it is that you've entered some horrible exception loop where > the exception handler causes another exception, and this repeats itself. > This would cause the stack to overwrite memory (as exception stack frames > stack up one on top of the other on top of the other...), taking out > pagetable pages as it goes. You'd then hang or crash when enough memory is > overwitten that the exception loop gets broken. > > Since the root cause of the exceptions happened some time back in > execution, > this could be a pain to debug. :-) And my theory may not even be correct... > > -- Keir > > > [-- Attachment #1.2: Type: text/html, Size: 2306 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-23 18:27 ` Keir Fraser 2009-04-23 20:16 ` Tom Rotenberg @ 2009-04-26 10:59 ` Tom Rotenberg 2009-04-26 11:14 ` Tom Rotenberg 1 sibling, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-26 10:59 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 1944 bytes --] Keir, I'm trying to figure out what causes the bug i'm experiencing, and i suspect that the TSS patch you have sent me has bugs. I saw in your patch, that you are setting the attributes of the every user segment (including CS) to be 0xf3, which sets the segment type to Data R/W. Don't you need to set the CS segment type to be Code R/W? Tom 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com> > On 23/04/2009 19:00, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > > I have applied the patch, and it looks like now it passed this part. > However, > > now, it hangs, and doesn't show the PointSec pre-boot GUI. I have also > seen > > the following messages in 'xm dmesg': > > > > (XEN) HVM2: Booting from Hard Disk... > > (XEN) HVM2: Booting from 0000:7c00 > > (XEN) multi.c:3351:d2 write to pagetable during event injection: > cr2=0x2234bc, > > mfn=0x29c23 > > (XEN) multi.c:3351:d2 write to pagetable during event injection: > > cr2=0x1032ff8, mfn=0x28e32 > > (XEN) multi.c:3351:d2 write to pagetable during event injection: > > cr2=0x102fff8, mfn=0x28e2f > > > > Do u have any idea what may cause this problem? > > Those messages are usually rare and typically indicate that a guest > pagetable page has been recycled as a kernel stack page, and is being > written to as part of an exception/interrupt delivery. My guess for why > you're seeing it is that you've entered some horrible exception loop where > the exception handler causes another exception, and this repeats itself. > This would cause the stack to overwrite memory (as exception stack frames > stack up one on top of the other on top of the other...), taking out > pagetable pages as it goes. You'd then hang or crash when enough memory is > overwitten that the exception loop gets broken. > > Since the root cause of the exceptions happened some time back in > execution, > this could be a pain to debug. :-) And my theory may not even be correct... > > -- Keir > > > [-- Attachment #1.2: Type: text/html, Size: 2525 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-26 10:59 ` Tom Rotenberg @ 2009-04-26 11:14 ` Tom Rotenberg 2009-04-26 11:23 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-26 11:14 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 2131 bytes --] Just saw the reason for the 0xf3 attribute in the Intel Spec. Sorry... 2009/4/26 Tom Rotenberg <tom.rotenberg@gmail.com> > Keir, > > I'm trying to figure out what causes the bug i'm experiencing, and i > suspect that the TSS patch you have sent me has bugs. I saw in your patch, > that you are setting the attributes of the every user segment (including CS) > to be 0xf3, which sets the segment type to Data R/W. Don't you need to set > the CS segment type to be Code R/W? > > Tom > > 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com> > >> On 23/04/2009 19:00, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >> >> >> > I have applied the patch, and it looks like now it passed this part. >> However, >> > now, it hangs, and doesn't show the PointSec pre-boot GUI. I have also >> seen >> > the following messages in 'xm dmesg': >> > >> > (XEN) HVM2: Booting from Hard Disk... >> > (XEN) HVM2: Booting from 0000:7c00 >> > (XEN) multi.c:3351:d2 write to pagetable during event injection: >> cr2=0x2234bc, >> > mfn=0x29c23 >> > (XEN) multi.c:3351:d2 write to pagetable during event injection: >> > cr2=0x1032ff8, mfn=0x28e32 >> > (XEN) multi.c:3351:d2 write to pagetable during event injection: >> > cr2=0x102fff8, mfn=0x28e2f >> > >> > Do u have any idea what may cause this problem? >> >> Those messages are usually rare and typically indicate that a guest >> pagetable page has been recycled as a kernel stack page, and is being >> written to as part of an exception/interrupt delivery. My guess for why >> you're seeing it is that you've entered some horrible exception loop where >> the exception handler causes another exception, and this repeats itself. >> This would cause the stack to overwrite memory (as exception stack frames >> stack up one on top of the other on top of the other...), taking out >> pagetable pages as it goes. You'd then hang or crash when enough memory is >> overwitten that the exception loop gets broken. >> >> Since the root cause of the exceptions happened some time back in >> execution, >> this could be a pain to debug. :-) And my theory may not even be >> correct... >> >> -- Keir >> >> >> [-- Attachment #1.2: Type: text/html, Size: 3044 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-26 11:14 ` Tom Rotenberg @ 2009-04-26 11:23 ` Tom Rotenberg 2009-04-26 12:27 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-26 11:23 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 2978 bytes --] Keir/Tim Why did u add the check in load_seg() function x86_emulate.c: diff -r 8b152638adaa xen/arch/x86/x86_emulate/x86_emulate.c --- a/xen/arch/x86/x86_emulate/x86_emulate.c Thu Apr 23 16:22:48 2009 +0100 +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Thu Apr 23 18:47:17 2009 +0100 @@ -1099,7 +1099,7 @@ (ops->write_segment == NULL) ) return X86EMUL_UNHANDLEABLE; - if ( in_protmode(ctxt, ops) ) + if ( in_protmode(ctxt, ops) || !is_x86_user_segment(seg) ) return protmode_load_seg(seg, sel, ctxt, ops); Why is it needed? and what will happen in case we will need to emulate a load of user segment in protected mode? right now, it will just not be performed. is this even legal? Tom 2009/4/26 Tom Rotenberg <tom.rotenberg@gmail.com> > Just saw the reason for the 0xf3 attribute in the Intel Spec. > Sorry... > > 2009/4/26 Tom Rotenberg <tom.rotenberg@gmail.com> > > Keir, >> >> I'm trying to figure out what causes the bug i'm experiencing, and i >> suspect that the TSS patch you have sent me has bugs. I saw in your patch, >> that you are setting the attributes of the every user segment (including CS) >> to be 0xf3, which sets the segment type to Data R/W. Don't you need to set >> the CS segment type to be Code R/W? >> >> Tom >> >> 2009/4/23 Keir Fraser <keir.fraser@eu.citrix.com> >> >>> On 23/04/2009 19:00, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: >>> >>> >>> > I have applied the patch, and it looks like now it passed this part. >>> However, >>> > now, it hangs, and doesn't show the PointSec pre-boot GUI. I have also >>> seen >>> > the following messages in 'xm dmesg': >>> > >>> > (XEN) HVM2: Booting from Hard Disk... >>> > (XEN) HVM2: Booting from 0000:7c00 >>> > (XEN) multi.c:3351:d2 write to pagetable during event injection: >>> cr2=0x2234bc, >>> > mfn=0x29c23 >>> > (XEN) multi.c:3351:d2 write to pagetable during event injection: >>> > cr2=0x1032ff8, mfn=0x28e32 >>> > (XEN) multi.c:3351:d2 write to pagetable during event injection: >>> > cr2=0x102fff8, mfn=0x28e2f >>> > >>> > Do u have any idea what may cause this problem? >>> >>> Those messages are usually rare and typically indicate that a guest >>> pagetable page has been recycled as a kernel stack page, and is being >>> written to as part of an exception/interrupt delivery. My guess for why >>> you're seeing it is that you've entered some horrible exception loop >>> where >>> the exception handler causes another exception, and this repeats itself. >>> This would cause the stack to overwrite memory (as exception stack frames >>> stack up one on top of the other on top of the other...), taking out >>> pagetable pages as it goes. You'd then hang or crash when enough memory >>> is >>> overwitten that the exception loop gets broken. >>> >>> Since the root cause of the exceptions happened some time back in >>> execution, >>> this could be a pain to debug. :-) And my theory may not even be >>> correct... >>> >>> -- Keir >>> >>> >>> [-- Attachment #1.2: Type: text/html, Size: 4172 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-26 11:23 ` Tom Rotenberg @ 2009-04-26 12:27 ` Keir Fraser 2009-04-26 15:08 ` Tom Rotenberg 0 siblings, 1 reply; 43+ messages in thread From: Keir Fraser @ 2009-04-26 12:27 UTC (permalink / raw) To: Tom Rotenberg; +Cc: Tim Deegan, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 1026 bytes --] That chunk actually has no effect right now, as we should never load a non-user segment while in real mode. You could throw that patch chunk away if you like. -- Keir On 26/04/2009 12:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > Keir/Tim > > Why did u add the check in load_seg() function x86_emulate.c: > diff -r 8b152638adaa xen/arch/x86/x86_emulate/x86_emulate.c > --- a/xen/arch/x86/x86_emulate/x86_emulate.c Thu Apr 23 16:22:48 2009 +0100 > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Thu Apr 23 18:47:17 2009 +0100 > @@ -1099,7 +1099,7 @@ > (ops->write_segment == NULL) ) > return X86EMUL_UNHANDLEABLE; > > - if ( in_protmode(ctxt, ops) ) > + if ( in_protmode(ctxt, ops) || !is_x86_user_segment(seg) ) > return protmode_load_seg(seg, sel, ctxt, ops); > > Why is it needed? and what will happen in case we will need to emulate a load > of user segment in protected mode? right now, it will just not be performed. > is this even legal? [-- Attachment #1.2: Type: text/html, Size: 1504 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-26 12:27 ` Keir Fraser @ 2009-04-26 15:08 ` Tom Rotenberg 2009-04-26 15:45 ` Keir Fraser 0 siblings, 1 reply; 43+ messages in thread From: Tom Rotenberg @ 2009-04-26 15:08 UTC (permalink / raw) To: Keir Fraser; +Cc: Tim Deegan, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 2179 bytes --] Keir/Tim, I have a question: i ran into the following code at vmx.c: /* Can't inject exceptions in virtual 8086 mode because they would * use the protected-mode IDT. Emulate at the next vmenter instead. */ if ( curr->arch.hvm_vmx.vmx_realmode ) curr->arch.hvm_vmx.vmx_emulate = 1; And i wonder if this has something to do with the problem i 'm experiencing. First, i don't understand this code, since the comment is talking about vm86 mode, while the actual code checks for realmode. Is this ok? Second, i wonder if there is a problem in updating the current state of the CPU, if it was changed during a task-switch (to vm86 mode), and it wasn't updated in the arch.hvm_vmx.vmx_realmode flag, then this might cause the problem, no? And last: i found that the last trap/event which is re-happening all the time, and by that trashes all the memory untill the domain crashes, is trap 0x20, which i'm not sure, but i think it's a system call. Do u have any reason to think why trap 0x20, could lead to this problem? maybe there is a bug in the task-switch code which might cause it? Tom 2009/4/26 Keir Fraser <keir.fraser@eu.citrix.com> > That chunk actually has no effect right now, as we should never load a > non-user segment while in real mode. You could throw that patch chunk away > if you like. > > -- Keir > > On 26/04/2009 12:23, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > > Keir/Tim > > Why did u add the check in load_seg() function x86_emulate.c: > diff -r 8b152638adaa xen/arch/x86/x86_emulate/x86_emulate.c > --- a/xen/arch/x86/x86_emulate/x86_emulate.c Thu Apr 23 16:22:48 2009 > +0100 > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Thu Apr 23 18:47:17 2009 > +0100 > @@ -1099,7 +1099,7 @@ > (ops->write_segment == NULL) ) > return X86EMUL_UNHANDLEABLE; > > - if ( in_protmode(ctxt, ops) ) > + if ( in_protmode(ctxt, ops) || !is_x86_user_segment(seg) ) > return protmode_load_seg(seg, sel, ctxt, ops); > > Why is it needed? and what will happen in case we will need to emulate a > load of user segment in protected mode? right now, it will just not be > performed. is this even legal? > > [-- Attachment #1.2: Type: text/html, Size: 2991 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM 2009-04-26 15:08 ` Tom Rotenberg @ 2009-04-26 15:45 ` Keir Fraser 0 siblings, 0 replies; 43+ messages in thread From: Keir Fraser @ 2009-04-26 15:45 UTC (permalink / raw) To: Tom Rotenberg; +Cc: Tim Deegan, xen-devel@lists.xensource.com On 26/04/2009 16:08, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote: > And i wonder if this has something to do with the problem i 'm experiencing. > First, i don't understand this code, since the comment is talking about vm86 > mode, while the actual code checks for realmode. Is this ok? Yes, Xen tries to emulate real mode by running the guest in vm86 mode. This is faster than full emulation. You have a guest that really is in vm86 mode (not merely to emulate real mode). > Second, i wonder if there is a problem in updating the current state of the > CPU, if it was changed during a task-switch (to vm86 mode), and it wasn't > updated in the arch.hvm_vmx.vmx_realmode flag, then this might cause the > problem, no? No, the guest isn't in real mode, it really is in vm86 mode. > And last: i found that the last trap/event which is re-happening all the time, > and by that trashes all the memory untill the domain crashes, is trap 0x20, > which i'm not sure, but i think it's a system call. Do u have any reason to > think why trap 0x20, could lead to this problem? Trap 0x20 is either a hardware interrupt or a software interrupt. Since the meaning of vectors >=0x20 is configured by software, we can't know what vector 0x20 is being used for here. However, often the 8259 PIC is based at vector 0x20, and that might mean that this recurring interrupt is the PIT (programmable interval timer). > maybe there is a bug in the task-switch code which might cause it? You wish. ;-) -- Keir ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2009-04-26 15:45 UTC | newest] Thread overview: 43+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-04-22 8:50 Doamin crash when trying to install disk encryption (PointSec) on Windows HVM Tom Rotenberg 2009-04-22 10:53 ` Keir Fraser 2009-04-22 11:18 ` Tom Rotenberg 2009-04-22 11:50 ` Keir Fraser 2009-04-22 12:39 ` Tom Rotenberg 2009-04-22 12:59 ` Keir Fraser 2009-04-22 13:02 ` Keir Fraser 2009-04-22 13:12 ` Tim Deegan 2009-04-22 13:23 ` Tom Rotenberg 2009-04-22 13:31 ` Tim Deegan 2009-04-22 13:34 ` Keir Fraser 2009-04-22 13:41 ` Tim Deegan 2009-04-22 13:52 ` Tom Rotenberg 2009-04-22 13:59 ` Keir Fraser 2009-04-22 14:04 ` Tom Rotenberg 2009-04-22 14:14 ` Keir Fraser 2009-04-22 14:20 ` Tom Rotenberg 2009-04-22 14:25 ` Keir Fraser 2009-04-22 14:40 ` Tom Rotenberg 2009-04-22 14:48 ` Keir Fraser 2009-04-22 14:53 ` Tom Rotenberg 2009-04-23 9:56 ` Tom Rotenberg 2009-04-23 10:42 ` Keir Fraser 2009-04-23 11:44 ` Tom Rotenberg 2009-04-23 12:15 ` Keir Fraser 2009-04-23 14:08 ` Tom Rotenberg 2009-04-23 14:28 ` Keir Fraser 2009-04-23 15:57 ` Tom Rotenberg 2009-04-23 16:01 ` Tim Deegan 2009-04-23 16:10 ` Tom Rotenberg 2009-04-23 17:16 ` Keir Fraser 2009-04-23 17:27 ` Keir Fraser 2009-04-23 17:38 ` Tom Rotenberg 2009-04-23 17:49 ` Keir Fraser 2009-04-23 18:00 ` Tom Rotenberg 2009-04-23 18:27 ` Keir Fraser 2009-04-23 20:16 ` Tom Rotenberg 2009-04-26 10:59 ` Tom Rotenberg 2009-04-26 11:14 ` Tom Rotenberg 2009-04-26 11:23 ` Tom Rotenberg 2009-04-26 12:27 ` Keir Fraser 2009-04-26 15:08 ` Tom Rotenberg 2009-04-26 15:45 ` Keir Fraser
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.