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

[Tom Rotenberg <tom.rotenberg@xxxxxxxxx>]

So, do u suggest, that i will set HVM_PARAM_VM86_TSS to 0, and re-check it?

2009/4/22 Tim Deegan <Tim.Deegan@xxxxxxxxxx>

At 14:34 +0100 on 22 Apr (1240410866), Keir Fraser wrote:
> It could be an issue with the vm86 acceleration, possibly. I'm pretty sure
> the guest would have to IRET from protected mode to enter vm86 mode itself,
> and we don't emulate that. Tim: what would we need to do to disable the vm86
> acceleration for testing purposes? You suggested not setting VM86_TSS param
> from hvmloader, but I couldn't convince myself what effect that would
> actually have as the logic in Xen is non-trivial.

Yes; if HVM_PARAM_VM86_TSS is zero, vmx_set_segment_register() will
always set the tss bit in the bitmap of segments that aren't safe to
enter VM86 with.

Tim.

>
> �-- Keir
>
> On 22/04/2009 14:23, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> wrote:
>
> > Tim,
> >
> > so what does it mean? could it be that we have a bug in the real mode
> > emulation, which causes the segment state to be invalid (maybe it's because of
> > a bug in the patch that Keir made for me, which emulated the LLDT, and the LTR
> > instructions)?
> >
> > Keir suggested to trace back where the problem (segment state) occured, and
> > from there to try and find the bug which caused it. Do u have any better
> > suggestion for solving this?
> >
> > Tom
> >
> > 2009/4/22 Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> >> At 13:39 +0100 on 22 Apr (1240407546), Tom Rotenberg wrote:
> >>> Keir,
> >>>
> >>> I have tried your latest patch, and it looks like now it passes the
> >>> emulation problem. However, �now the domain crashes 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=0x000000000a213a20, 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
> >>
> >> Looks like we're trying to VMENTER in virtual 8086 mode but without
> >> tidying up the segment state. �That could either be the guest entering
> >> virtual 8086 mode itself or Xen entering vitrual 8086 mode to emulate
> >> real mode, but Xen is always careful to make the segment state agree
> >> with Intel's rather strict requrements when it does that.
> >>
> >> Tim.
> >>
> >>
> >>> (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000
> >>> (XEN) CS: sel=0x0060, attr=0x0c09b, limit=0xffffffff,
> >>> base=0x0000000000200000
> >>> (XEN) DS: sel=0x0068, attr=0x0c093, limit=0xffffffff,
> >>> base=0x0000000000200000
> >>> (XEN) SS: sel=0x0070, attr=0x0c093, limit=0xfc000fff,
> >>> base=0x000000000020ba62
> >>> (XEN) ES: sel=0x0068, attr=0x0c093, limit=0xffffffff,
> >>> base=0x0000000000200000
> >>> (XEN) FS: sel=0x0068, attr=0x0c093, limit=0xffffffff,
> >>> base=0x0000000000200000
> >>> (XEN) GS: sel=0x0068, attr=0x0c093, limit=0xffffffff,
> >>> base=0x0000000000200000
> >>> (XEN) GDTR: � � � � � � � � � � � � � limit=0x00001dd8,
> >>> base=0x0000000000200000
> >>> (XEN) LDTR: sel=0x0000, attr=0x1c000, limit=0xffffffff,
> >>> 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 = ffffffe4920110b7
> >>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000
> >>> (XEN) Interruptibility=0001 ActivityState=0000
> >>> (XEN) *** Host State ***
> >>> (XEN) RSP = 0xffff83007e4f7fa0 �RIP = 0xffff828c8019aa20
> >>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040
> >>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000
> >>> TRBase=ffff828c802a8b00
> >>> (XEN) GDTBase=ffff83007e9a3000 IDTBase=ffff83007e62e010
> >>> (XEN) CR0=0000000080050033 CR3=000000007cfdc000 CR4=00000000000026f0
> >>> (XEN) Sysenter RSP=ffff83007e4f7fd0 CS:RIP=e008:ffff828c801c7290
> >>> (XEN) Host PAT = 0x0000000000000000
> >>> (XEN) *** Control State ***
> >>> (XEN) PinBased=0000003f CPUBased=b6a1e7fe SecondaryExec=00000041
> >>> (XEN) EntryControls=000011ff ExitControls=0003efff
> >>> (XEN) ExceptionBitmap=00044080
> >>> (XEN) VMEntry: intr_info=80000b0b errcode=00001eac 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) **************************************
> >>> (XEN) domain_crash called from vmx.c:2218
> >>> (XEN) Domain 1 (vcpu#0) crashed on cpu#1:
> >>> (XEN) ----[ Xen-3.4.0-rc3-pre �x86_64 �debug=n �Not tainted ]----
> >>> (XEN) CPU: � �1
> >>> (XEN) RIP: � �0060:[<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: 0068 � es: 0068 � fs: 0068 � gs: 0068 � ss: 0070 � cs: 0060
> >>>
> >>> Could it be, that the real mode emulation code has a bug? What does this
> >>> error means?
> >>>
> >>> Tom
> >>>
> >>> 2009/4/22 Keir Fraser
> >>> <keir.fraser@xxxxxxxxxxxxx<mailto:keir.fraser@xxxxxxxxxxxxx>>
> >>> On 22/04/2009 12:18, "Tom Rotenberg"
> >>> <tom.rotenberg@xxxxxxxxx<mailto:tom.rotenberg@xxxxxxxxx>> wrote:
> >>>
> >>>> Keir,
> >>>>
> >>>> I have applied your patch, and it seemed to work. However, the domain still
> >>>> crashes, and now it looks like it's because of the 'LTR' instruction.
> >>>
> >>> Try the attached patch. It replaces the one I sent last time, and emulates
> >>> both LLDT and LTR.
> >>>
> >>> �-- Keir
> >>>
> >>
> >> Content-Description: ATT00001.txt
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@xxxxxxxxxxxxxxxxxxx
> >>> http://lists.xensource.com/xen-devel
> >>
> >>
> >> --
> >> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> >> Principal Software Engineer, Citrix Systems (R&D) Ltd.
> >> [Company #02300071, SL9 0DZ, UK.]
> >
>
>

--

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