|
[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
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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |