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

[Tom Rotenberg <tom.rotenberg@xxxxxxxxx>]

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

Patch is attached. It is in addition to the LTR/LLDT patch.

 -- Keir

On 23/04/2009 18:16, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> 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@xxxxxxxxx> wrote:
>
>> So, do u have any suggestion, on how can i fix this issue?
>>
>> 2009/4/23 Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>>> 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@xxxxxxxxxxxxx<mailto:keir.fraser@xxxxxxxxxxxxx>>
>>>> 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@xxxxxxxxx<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@xxxxxxxxxxxxx<http://keir.fraser@eu.citrix.com
>>>> <http://eu.citrix.com> >>
>>>> On 23/04/2009 12:44, "Tom Rotenberg"
>>>> <tom.rotenberg@xxxxxxxxx<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@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