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