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/
Home Products Support Community News


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

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 20:38:45 +0300
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 23 Apr 2009 10:40:03 -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=/qw2moGYpK5r8PAwbIJCOfgda7KQ3MuqDL6x5i3mF5M=; b=naced+lBsW2LVjVmMdUycVxw3qL2xPAD9O8ubNLTPetpP2rhX52eFZftQBe3hUj0iH ssxejPVxSatbUBEqTxST+W8VCAiemiw1UzqXP72cedWy4pqMSKy0phYzrOKjHUpa/YNf R9p2+pCuVzWN3LEN1eXgtFaSrjtnyJ4nFs7y4=
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=cxGCzXV6ZOPyESqPIBlG/iSew8IcH9Kb9miOQNyuFQT3XeUzCllXJunHkUojgQZNFs yvO0Ag2dB4anl8VDsIFlIfoRNbudafmmho1eDzZJmpiNdaAO5Mlsc7Sz0xWkkJYTJgYS TSfdrLBHsd1Vrc44V8l5+sOuQPnYn0/f/dVDA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C6166375.95DF%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: <C61660FE.95D7%keir.fraser@xxxxxxxxxxxxx> <C6166375.95DF%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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?


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
<Prev in Thread] Current Thread [Next in Thread>