[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


  • To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • From: Tom Rotenberg <tom.rotenberg@xxxxxxxxx>
  • Date: Sun, 26 Apr 2009 18:08:56 +0300
  • Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Sun, 26 Apr 2009 08:09:32 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lRTa3E5CwEK5J4oAww9+KshkwgFI0M7VdiiYPFdtdEW94EcqNGECPR59FxAeDgSX2J gC+cewZAks6zF1NKsgG/iJ2XRtg9sgpp74Wc8KMmvg8GMsFXLogziw/bcB5hI48FuTZ0 ZRCOSbPGDZ78Qt4m1HSXa0j+qp+PWMzXuaocE=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Keir/Tim,

I have a question: i ran into the following code at vmx.c:
    /* Can't inject exceptions in virtual 8086 mode because they would
     * use the protected-mode IDT.  Emulate at the next vmenter instead. */
    if ( curr->arch.hvm_vmx.vmx_realmode )
        curr->arch.hvm_vmx.vmx_emulate = 1;

And i wonder if this has something to do with the problem i 'm experiencing. First, i don't understand this code, since the comment is talking about vm86 mode, while the actual code checks for realmode. Is this ok?

Second, i wonder if there is a problem in updating the current state of the CPU, if it was changed during a task-switch (to vm86 mode), and it wasn't updated in the arch.hvm_vmx.vmx_realmode flag, then this might cause the problem, no?

And last: i found that the last trap/event which is re-happening all the time, and by that trashes all the memory untill the domain crashes, is trap 0x20, which i'm not sure, but i think it's a system call. Do u have any reason to think why trap 0x20, could lead to this problem? maybe there is a bug in the task-switch code which might cause it?

Tom

2009/4/26 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
That chunk actually has no effect right now, as we should never load a non-user segment while in real mode. You could throw that patch chunk away if you like.

 -- Keir


On 26/04/2009 12:23, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> wrote:

Keir/Tim

Why did u add the check in load_seg() function x86_emulate.c:
diff -r 8b152638adaa xen/arch/x86/x86_emulate/x86_emulate.c
--- a/xen/arch/x86/x86_emulate/x86_emulate.c    Thu Apr 23 16:22:48 2009 +0100
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c    Thu Apr 23 18:47:17 2009 +0100
@@ -1099,7 +1099,7 @@
          (ops->write_segment == NULL) )
         return X86EMUL_UNHANDLEABLE;
 
-    if ( in_protmode(ctxt, ops) )
+    if ( in_protmode(ctxt, ops) || !is_x86_user_segment(seg) )
         return protmode_load_seg(seg, sel, ctxt, ops);

Why is it needed? and what will happen in case we will need to emulate a load of user segment in protected mode? right now, it will just not be performed. is this even legal?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.