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@
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
>
> On 23/04/2009 12:44, "Tom Rotenberg" <
tom.rotenberg@xxxxxxxxx<
http://tom.rotenberg@
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.]
