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

[Tom Rotenberg <tom.rotenberg@xxxxxxxxx>]

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?

Tom

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...

Tom

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel