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 (Poi

To: Tom Rotenberg <tom.rotenberg@xxxxxxxxx>
Subject: Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 23 Apr 2009 15:28:08 +0100
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 23 Apr 2009 07:28:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <8686c3cd0904230708w7e0f41c3he3ed303573d52e38@xxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcnEHP85yWo+HYFrRx6lbMtaKZXUdwAArmTd
Thread-topic: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM
User-agent: Microsoft-Entourage/
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>