From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [hybrid]: unable to boot hvm due to eflags.ID Date: Fri, 4 May 2012 10:08:22 +0100 Message-ID: <1336122502.2361.7.camel@zakaz.uk.xensource.com> References: <20120503191025.7c2cec2e@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120503191025.7c2cec2e@mantra.us.oracle.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: Mukesh Rathor Cc: "Xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Fri, 2012-05-04 at 03:10 +0100, Mukesh Rathor wrote: > Hi guys, > > At a loss trying to figure why > if (has_eflag(X86_EFLAGS_ID)) > > returns false in my HVM domU. Standard function has_eflag() in > cpucheck.c running in real mode. Works fine on PV dom0, Are you sure code in cpucheck.c is even being called for the PV/dom0 case? I'm reasonably sure that PV Xen boot doesn't go anywhere near arch/x86/boot -- we have a totally different entry point. > but fails when guest is booting on my hybrid dom0. 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? How does that interact with EFLAGS_ID I wonder (although why hybrid dom0 would have any bearing on this I've no idea). > LMK if any ideas. I'll keep digging in the manuals, but nothing so far. > > thanks, > Mukesh > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel