[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • From: Tom Rotenberg <tom.rotenberg@xxxxxxxxx>
  • Date: Wed, 22 Apr 2009 17:20:26 +0300
  • Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 22 Apr 2009 07:21:03 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sWBx6l3X13u0+Co7dIYeBbElOHGkDInTP8MO7Q+PYwtJvuqrvrKN8rxYd3Q/zA1K+S lDeJozMHDAmpZqVN1LOSsb7YskxnZ7EcRpg9vP8Jp/Ov4RcM+5zDSr5+ANqxZFdziMCR eWa91aNZVeHLeuO5XrrbiupKVumXkkxL662NU=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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@xxxxxxxxxxxxx>
That should do it.

 K.


On 22/04/2009 15:04, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> 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@xxxxxxxxxxxxx>
>> 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@xxxxxxxxx> 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@xxxxxxxxxx>
>>>> 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@xxxxxxxxx> 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@xxxxxxxxxx>
>>>>>>> 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@xxxxxxxxxxxxx<mailto:keir.fraser@xxxxxxxxxxxxx>>
>>>>>>>> On 22/04/2009 12:18, "Tom Rotenberg"
>>>>>>>> <tom.rotenberg@xxxxxxxxx<mailto:tom.rotenberg@xxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx
>>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd.
>>>>>>> [Company #02300071, SL9 0DZ, UK.]
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd.
>>>> [Company #02300071, SL9 0DZ, UK.]
>>>
>>
>>
>


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.