WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 		  
Home Products Support Community News
 
   
 

xen-devel

[Top] [All Lists]
<prev [Date] next>
[Advanced]
 <prev [Thread] next>

Re: [Xen-devel] Doamin crash when trying to install disk encryption (Po

from [Tom Rotenberg] [Permanent Link][Original]
To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM
From: Tom Rotenberg <tom.rotenberg@xxxxxxxxx>
Date: Thu, 23 Apr 2009 14:44:04 +0300
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 23 Apr 2009 04:44:47 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Ldp9cfxPEBXHonLHgVy0YEfrOjFNTOII7gwBoWmnUPI=; b=LnPFC19u/klnUdHsY9D6dH61mSQPqL6sTRO5lfCUI2HRJDr+7wM3aI2Qb2xDtj9Yb/ zwI/zeTvb/ellsMVD+T2gzdf97VClO/oQvjthmZqqaSuP/Y/sdxq3T3rSsUf3f8nbd7M dA0bU0g+C0oq2mQvIK0JBpJ3N1bPjeMH/GLGI=
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=Y/kp8UMwpYjPWI7TSJrOZKoQfCg+93hbDeIEQBeV5apZ1UUDrfJ6ZkoyhGIcT36538 FduhjuaAVCTXwdRu3qMrv0qAZL0kC0TetZIx+S5iPXukTi4ouGM0dkswr997x71e3FDD 3k42D6+sscOnuQelcTBUUlIMnXIWZ2Lwz6u80=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C61604C0.94AA%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <8686c3cd0904230256x792782bu744776fdd3d9903e@xxxxxxxxxxxxxx> <C61604C0.94AA%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxx>
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@xxxxxxxxx> 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@xxxxxxxxxxxxx>
>> On 22/04/2009 15:40, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> 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@xxxxxxxxxxxxx>
>>>> 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@xxxxxxxxx> 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@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
[More with this subject...]
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date:  [Xen-devel] RE: [Xen-users] XEN Infiniband, Robert Dunkley
Next by Date:  Re: [Xen-devel] Re: NX related build failure in latest pv_ops dom0 hackery tree, Marc - A. Dahlhaus [ Administration | Westermann GmbH ]
Previous by Thread:  Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM, Keir Fraser
Next by Thread:  Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM, Keir Fraser
Indexes:  [Date] [Thread] [Top] [All Lists]
 
   

Copyright , Citrix Systems Inc. All rights reserved. Legal and Privacy