This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain

To: Brady Chen <chenchp@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Tue, 07 Aug 2007 10:29:37 +0100
Cc: tygrawy@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Z24 <z24@xxxxxxx>, AL.LINUX@xxxxxxxxxxx
Delivery-date: Tue, 07 Aug 2007 02:27:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <8fec1fce0708070206u423d8636va32a989c9856e233@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfY1XjRt3+hqkTIEdyCkgAX8io7RQ==
Thread-topic: [Xen-devel] Re: [Xen-users] boot a existing windows in hvm domain
User-agent: Microsoft-Entourage/
On 7/8/07 10:06, "Brady Chen" <chenchp@xxxxxxxxx> wrote:

> the dmesg shows some instructions have being simulated.
> so they should be the codes just before d0900 or d0800, am i right?

No. What is happening is that vmxassist is trying to emulate as far as it
can into real-mode execution at around linear address d71b-d71f, until it
sees an instruction that it cannot decode. When it sees an instruction it
does not understand it prints out "opc <opcode number>". Since there is no
such output immediately before the trap, this means that vmxassist was still
in its emulation loop and vmxassist itself crashed. This makes sense because
the faulting eip is somewhere in vmxassist's code (albeit not on an
instruction boundary!). The faulting linear address is definitely d0800, so
that is the interesting area of the vmxassist objdump.

What would be useful is to try to add tracing to see how far vmxassist gets
after its last line of tracing before the trap occurs. That last line is
currently from vm86.c, line 620. You might try adding extra printf()
statements imemdiately after the write16() on line 622, and also at the top
of the opcode() function. We need to find out at what point vmxassist is
jumping to this bogus address d0800.

 -- Keir

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>