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 18:57:29 +0300
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 23 Apr 2009 08:58:28 -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=M5jTnSP1kjsDIR+EEJtyKgE90gWk1IOgtf7rHEeBH90=; b=WhcPBpw+5oZ/V1b1X12h/iQHsCN0Byz5nRo4Ca7618K+XNSR8k4ydv9oGoP96hvovJ KbCKYuiFvmCwz1HGG8WUfoedXIP4fUlyQnUqElQGdsKGkOfu4tockgKVLlDVko8cbiDs xHIgcp9f8M0QXSeBynSA2RQf+uUeIZHAAorKY=
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=XLS4eXweVpOjyGLm5vmYGyw+BdLvKsu24GrqgWNbXtRAeWCBojOp/1PexogU1c3zYc WziFgM9AhYgTA36hWb6KOwfQwusfeNp4U+4iSlGpV5eO6BJeNZIMWbB8nmIAEdJbIID3 4eNBeBk0P60woWFujpLY6f16skBvh0UYKWneg=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C6163988.959C%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: <8686c3cd0904230708w7e0f41c3he3ed303573d52e38@xxxxxxxxxxxxxx> <C6163988.959C%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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?


2009/4/23 Keir Fraser <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> 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...


2009/4/23 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
On 23/04/2009 12:44, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> 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).

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>