From: Keir Fraser <keir.fraser@eu.citrix.com>
To: Tom Rotenberg <tom.rotenberg@gmail.com>
Cc: Tim Deegan <Tim.Deegan@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM
Date: Wed, 22 Apr 2009 15:14:59 +0100 [thread overview]
Message-ID: <C614E4F3.93AB%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <8686c3cd0904220704l4d068ce0h6cb21ff49fcfcb51@mail.gmail.com>
That should do it.
K.
On 22/04/2009 15:04, "Tom Rotenberg" <tom.rotenberg@gmail.com> wrote:
> Keir,
> Just to make sure, i am using the following patch, in order to disable the
> vm86 acceleration:
>
> diff -r cdc044f665dc xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 11:26:37 2009 +0100
> +++ b/xen/arch/x86/hvm/vmx/vmx.c Wed Apr 22 17:03:20 2009 +0300
> @@ -829,7 +829,7 @@
>
> if ( seg == x86_seg_tr )
> {
> - if ( v->domain->arch.hvm_domain.params[HVM_PARAM_VM86_TSS] )
> + if (0)
> {
> sel = 0;
> attr = vm86_tr_attr;
>
> Is this OK?
>
> Tom
>
> 2009/4/22 Keir Fraser <keir.fraser@eu.citrix.com>
>> 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@gmail.com> 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@citrix.com>
>>>> 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@gmail.com> 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@citrix.com>
>>>>>>> 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@eu.citrix.com<mailto:keir.fraser@eu.citrix.com>>
>>>>>>>> On 22/04/2009 12:18, "Tom Rotenberg"
>>>>>>>> <tom.rotenberg@gmail.com<mailto:tom.rotenberg@gmail.com>> 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@lists.xensource.com
>>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Tim Deegan <Tim.Deegan@citrix.com>
>>>>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd.
>>>>>>> [Company #02300071, SL9 0DZ, UK.]
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Tim Deegan <Tim.Deegan@citrix.com>
>>>> Principal Software Engineer, Citrix Systems (R&D) Ltd.
>>>> [Company #02300071, SL9 0DZ, UK.]
>>>
>>
>>
>
next prev parent reply other threads:[~2009-04-22 14:14 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-22 8:50 Doamin crash when trying to install disk encryption (PointSec) on Windows HVM Tom Rotenberg
2009-04-22 10:53 ` Keir Fraser
2009-04-22 11:18 ` Tom Rotenberg
2009-04-22 11:50 ` Keir Fraser
2009-04-22 12:39 ` Tom Rotenberg
2009-04-22 12:59 ` Keir Fraser
2009-04-22 13:02 ` Keir Fraser
2009-04-22 13:12 ` Tim Deegan
2009-04-22 13:23 ` Tom Rotenberg
2009-04-22 13:31 ` Tim Deegan
2009-04-22 13:34 ` Keir Fraser
2009-04-22 13:41 ` Tim Deegan
2009-04-22 13:52 ` Tom Rotenberg
2009-04-22 13:59 ` Keir Fraser
2009-04-22 14:04 ` Tom Rotenberg
2009-04-22 14:14 ` Keir Fraser [this message]
2009-04-22 14:20 ` Tom Rotenberg
2009-04-22 14:25 ` Keir Fraser
2009-04-22 14:40 ` Tom Rotenberg
2009-04-22 14:48 ` Keir Fraser
2009-04-22 14:53 ` Tom Rotenberg
2009-04-23 9:56 ` Tom Rotenberg
2009-04-23 10:42 ` Keir Fraser
2009-04-23 11:44 ` Tom Rotenberg
2009-04-23 12:15 ` Keir Fraser
2009-04-23 14:08 ` Tom Rotenberg
2009-04-23 14:28 ` Keir Fraser
2009-04-23 15:57 ` Tom Rotenberg
2009-04-23 16:01 ` Tim Deegan
2009-04-23 16:10 ` Tom Rotenberg
2009-04-23 17:16 ` Keir Fraser
2009-04-23 17:27 ` Keir Fraser
2009-04-23 17:38 ` Tom Rotenberg
2009-04-23 17:49 ` Keir Fraser
2009-04-23 18:00 ` Tom Rotenberg
2009-04-23 18:27 ` Keir Fraser
2009-04-23 20:16 ` Tom Rotenberg
2009-04-26 10:59 ` Tom Rotenberg
2009-04-26 11:14 ` Tom Rotenberg
2009-04-26 11:23 ` Tom Rotenberg
2009-04-26 12:27 ` Keir Fraser
2009-04-26 15:08 ` Tom Rotenberg
2009-04-26 15:45 ` Keir Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C614E4F3.93AB%keir.fraser@eu.citrix.com \
--to=keir.fraser@eu.citrix.com \
--cc=Tim.Deegan@eu.citrix.com \
--cc=tom.rotenberg@gmail.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.