From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [hybrid]: unable to boot hvm due to eflags.ID Date: Fri, 4 May 2012 11:49:02 +0100 Message-ID: <20120504104902.GA6127@ocelot.phlegethon.org> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> <1336122502.2361.7.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1336122502.2361.7.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "Xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org At 10:08 +0100 on 04 May (1336126102), Ian Campbell wrote: > What does the guest EFLAGS actually contain at this point? Is it > different to what it contains on non-hybrid dom0? > > How do we execute 16 bit code in a VMX guest these days, using vm86 or > by emulation? Both, and also sometimes neither. :) If the chip supports it, we just run in real mode inside the VM (this is called "unrestricted guest" in the VMX code and will be reported in the Xen boot messages). Otherwise we run in vm86 when we can, and emulate things that vm86 doesn't support, and all I/O. We also have to emulate when the segment state is wierd (e.g., big-real-mode) because the VMENTER into vm86 has stricter checks on segment state than actual real mode. > How does that interact with EFLAGS_ID I wonder (although > why hybrid dom0 would have any bearing on this I've no idea). I'm not aware of anything deliberately tinkering with EFLAGS_ID, but it's possible that vm86 interacts with it (of that we accidentally lose some parts of EFLAGS in emulation). Tim.