I applied the patch, and it seems it helped a little, however, the domain is still crashing, with the following error:
(XEN) HVM1: Booting from 0000:7c00
(XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state (0).
(XEN) ************* VMCS Area **************
(XEN) *** Guest State ***
(XEN) CR0: actual=0x0000000080010039, shadow=0x0000000080000019, gh_mask=ffffffffffffffff
(XEN) CR4: actual=0x0000000000002060, shadow=0x0000000000000000, gh_mask=ffffffffffffffff
(XEN) CR3: actual=0x000000000a211a20, target_count=0
(XEN) target0=0000000000000000, target1=0000000000000000
(XEN) target2=0000000000000000, target3=0000000000000000
(XEN) RSP = 0x0000000000000080 (0x0000000000000080) RIP = 0x000000000000002a (0x000000000000002a)
(XEN) RFLAGS=0x0000000000023202 (0x0000000000023202) DR7 = 0x0000000000000400
(XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000
(XEN) CS: sel=0x14a2, attr=0x000f3, limit=0x0000ffff, base=0x0000000000014a20
(XEN) DS: sel=0x1da8, attr=0x000f3, limit=0x0000ffff, base=0x000000000001da80
(XEN) SS: sel=0x1ea6, attr=0x000f3, limit=0x0000ffff, base=0x000000000001ea60
(XEN) ES: sel=0x1eae, attr=0x000f3, limit=0x0000ffff, base=0x000000000001eae0
(XEN) FS: sel=0x0000, attr=0x000f3, limit=0x0000ffff, base=0x0000000000000000
(XEN) GS: sel=0x0000, attr=0x000f3, limit=0x0000ffff, base=0x0000000000000000
(XEN) GDTR: limit=0x00001dd8, base=0x0000000000200000
(XEN) LDTR: sel=0x0000, attr=0x000f3, limit=0x0000ffff, base=0x0000000000000000
(XEN) IDTR: limit=0x00000188, base=0x0000000000201df0
(XEN) TR: sel=0x0058, attr=0x0008b, limit=0x0000ffff, base=0x0000000000201ff2
(XEN) Guest PAT = 0x0000000000000000
(XEN) TSC Offset = ffffffcaa41ccde0
(XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000
(XEN) Interruptibility=0001 ActivityState=0000
(XEN) *** Host State ***
(XEN) RSP = 0xffff828c8026ffa0 RIP = 0xffff828c8019aa90
(XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040
(XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff828c802a8a80
(XEN) GDTBase=ffff828c800f3000 IDTBase=ffff828c802ac420
(XEN) CR0=0000000080050033 CR3=000000007cfd4000 CR4=00000000000026f0
(XEN) Sysenter RSP=ffff828c8026ffd0 CS:RIP=e008:ffff828c801c7290
(XEN) Host PAT = 0x0000000000000000
(XEN) *** Control State ***
(XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041
(XEN) EntryControls=000011ff ExitControls=0003efff
(XEN) VMEntry: intr_info=00000000 errcode=00000000 ilen=00000000
(XEN) VMExit: intr_info=00000000 errcode=00008000 ilen=00000000
(XEN) reason=80000021 qualification=00000000
(XEN) IDTVectoring: info=00000000 errcode=00000000
(XEN) TPR Threshold = 0x00
(XEN) EPT pointer = 0x0000000000000000
(XEN) Virtual processor ID = 0x0000
(XEN) domain_crash called from vmx.c:2218
(XEN) Domain 1 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.4.0-rc3-pre x86_64 debug=n Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: 14a2:[<000000000000002a>]
(XEN) RFLAGS: 0000000000023202 CONTEXT: hvm guest
(XEN) rax: 0000000000000007 rbx: 0000000000001490 rcx: 0000000000000000
(XEN) rdx: 0000000000001da8 rsi: 0000000000000000 rdi: 0000000000000000
(XEN) rbp: 0000000000008ebf rsp: 0000000000000080 r8: 0000000000000000
(XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000
(XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000
(XEN) r15: 0000000000000000 cr0: 0000000080000019 cr4: 0000000000000000
(XEN) cr3: 0000000001443000 cr2: 0000000000000000
(XEN) ds: 1da8 es: 1eae fs: 0000 gs: 0000 ss: 1ea6 cs: 14a2
Any ideas to what is wrong now?
2009/4/23 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Patch is attached. It is in addition to the LTR/LLDT patch.
On 23/04/2009 18:16, "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
>> 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:
>>>> 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
>>>> (!), and upon trying to resume from this vmexit, the cpu raised an
>>>> 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).
>>>> 2009/4/23 Keir Fraser
>>>> 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"
>>>> 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
>>>> 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...
>>>> 2009/4/23 Keir Fraser
>>>> On 23/04/2009 12:44, "Tom Rotenberg"
>>>>> However, from the VMCS dump, i saw data, which doesn't seem compatible
>>>>> 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.]