WARNING - OLD ARCHIVES

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

xen-devel

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

To: Tom Rotenberg <tom.rotenberg@xxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
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 18:16:30 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 23 Apr 2009 10:16:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <8686c3cd0904230910r1b9aca6ay512f6c6fc03a6a84@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: AcnELgHYRJ9tUinLQQqdm3BGcDK6DgACTw2H
Thread-topic: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM
User-agent: Microsoft-Entourage/12.17.0.090302
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@xxxxxxxxx <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@xxxxxxxxxxxxx
>>> <http://eu.citrix.com> >>
>>> On 23/04/2009 12:44, "Tom Rotenberg"
>>> <tom.rotenberg@xxxxxxxxx<http://tom.rotenberg@xxxxxxxxx <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

<Prev in Thread] Current Thread [Next in Thread>