thr3ads.net - Xen devel - [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM [Apr 2009]

If this information is useful, please help other people find it:
Share via:

Tom Rotenberg

2009-Apr-22 08:50 UTC

[Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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


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

Keir Fraser

2009-Apr-22 10:53 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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



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

Tom Rotenberg

2009-Apr-22 11:18 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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
>
>

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

Keir Fraser

2009-Apr-22 11:50 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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



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

Tom Rotenberg

2009-Apr-22 12:39 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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
>
>

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

Keir Fraser

2009-Apr-22 12:59 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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


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

Keir Fraser

2009-Apr-22 13:02 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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

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

Tim Deegan

2009-Apr-22 13:12 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]

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

Tom Rotenberg

2009-Apr-22 13:23 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
>

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

Tim Deegan

2009-Apr-22 13:31 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]

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

Keir Fraser

2009-Apr-22 13:34 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
> 


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

Tim Deegan

2009-Apr-22 13:41 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]

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

Tom Rotenberg

2009-Apr-22 13:52 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
>

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

Keir Fraser

2009-Apr-22 13:59 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
> 


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

Tom Rotenberg

2009-Apr-22 14:04 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
> >
>
>
>

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

Keir Fraser

2009-Apr-22 14:14 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
>>> 
>> 
>> 
> 


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

Tom Rotenberg

2009-Apr-22 14:20 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
> >>>
> >>
> >>
> >
>
>
>

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

Keir Fraser

2009-Apr-22 14:25 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 


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

Tom Rotenberg

2009-Apr-22 14:40 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
>

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

Keir Fraser

2009-Apr-22 14:48 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 


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

Tom Rotenberg

2009-Apr-22 14:53 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
>

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

Tom Rotenberg

2009-Apr-23 09:56 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
>

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

Keir Fraser

2009-Apr-23 10:42 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 


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

Tom Rotenberg

2009-Apr-23 11:44 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
>

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

Keir Fraser

2009-Apr-23 12:15 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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).


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

Tom Rotenberg

2009-Apr-23 14:08 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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).
>
>
>

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

Keir Fraser

2009-Apr-23 14:28 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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).
>> 
>> 
> 


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

Tom Rotenberg

2009-Apr-23 15:57 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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).
>
>
>
>

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

Tim Deegan

2009-Apr-23 16:01 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]

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

Tom Rotenberg

2009-Apr-23 16:10 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
>

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

Keir Fraser

2009-Apr-23 17:16 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
> 


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

Keir Fraser

2009-Apr-23 17:27 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
>> 
> 


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

Tom Rotenberg

2009-Apr-23 17:38 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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.]
> >>
> >
>
>

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

Keir Fraser

2009-Apr-23 17:49 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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



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

Tom Rotenberg

2009-Apr-23 18:00 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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
>
>

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

Keir Fraser

2009-Apr-23 18:27 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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



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

Tom Rotenberg

2009-Apr-23 20:16 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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
>
>
>

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

Tom Rotenberg

2009-Apr-26 10:59 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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
>
>
>

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

Tom Rotenberg

2009-Apr-26 11:14 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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
>>
>>
>>

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

Tom Rotenberg

2009-Apr-26 11:23 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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
>>>
>>>
>>>

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

Keir Fraser

2009-Apr-26 12:27 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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?


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

Tom Rotenberg

2009-Apr-26 15:08 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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?
>
>

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

Keir Fraser

2009-Apr-26 15:45 UTC

head link

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

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



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

Xen devel - Apr 2009 - Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

[Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM