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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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