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: Wed, 08 Aug 2007 21:26:24 +0100 Message-ID: References: <46ba0137.18e7300a.328b.ffffab4c@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <46ba0137.18e7300a.328b.ffffab4c@mx.google.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mats Petersson , Brady Chen Cc: tygrawy@gazeta.pl, xen-devel@lists.xensource.com, Z24 , AL.LINUX@bcpraha.com List-Id: xen-devel@lists.xenproject.org On 8/8/07 18:45, "Mats Petersson" wrote: > At 17:19 08/08/2007, Keir Fraser wrote: >> No, it's a processor mode halfway between real mode and protected mode which >> all x86 processors support, but which vmxassist is really rather bad at >> handling. If this is a big-real-mode copy loop then that might explain why >> the loop is executing so bizarrely, and may mean you are out of luck until >> we retire vmxassist. > > And the fact that EDI is 0xC33FE when it tries to write to the memory > at address of EDI indicates that it's Big-Real-Mode. Yes, that's a giveaway. So I think the 'fix' here is to not try booting your native Windows partition on Xen. It's not likely to work too well anyway, as it'll look like all your hardware has changed, causing activation problems and also big driver changes whenever you switch between running on Xen and running natively. You're better off having a dedicated Xen Windows installation, perhaps on an LVM partition. The problems that others have been seeing are quite likely not the same root cause as yours. Most times there's an early boot problem it will end up with a trap and backtrace in vmxassist, when running on Intel CPUs. -- Keir