From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: [Xen-users] boot a existing windows in hvm domain Date: Tue, 07 Aug 2007 10:35:24 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Brady Chen Cc: tygrawy@gazeta.pl, xen-devel@lists.xensource.com, Z24 , AL.LINUX@bcpraha.com List-Id: xen-devel@lists.xenproject.org On 7/8/07 10:29, "Keir Fraser" wrote: > 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. Oh, another possibility is that vmxassist has been corrupted in memory. This is particularly likely because, according to the objdump, the 'instruction' that starts at d0800 is actually valid (it'd be an ADD of some sort). So, within trap() you might want to read say 16 bytes starting at 0xd0800 and printf() them. So we can see if they match what objdump says should be there. -- Keir