|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM
Yes, the safest way to be sure is probably to replace the if() statement in vmx_set_segment_register() that tests HVM_PARAM_VM86_TSS with if(0). That is the only place in Xen that checks HVM_PARAM_VM86_TSS. Then you can re-build/install Xen and be sure that vm86 accel must be disabled. -- Keir On 22/04/2009 14:52, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> wrote: > 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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |