All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [hybrid]: unable to boot hvm due to eflags.ID
Date: Fri, 4 May 2012 11:53:27 +0100	[thread overview]
Message-ID: <1336128807.2361.56.camel@zakaz.uk.xensource.com> (raw)
In-Reply-To: <20120504104902.GA6127@ocelot.phlegethon.org>

On Fri, 2012-05-04 at 11:49 +0100, Tim Deegan wrote:
> 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. :) 

Of course ;-)

> 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).

Thanks, I thought this had been added but didn't know the name of the
feature.

> 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,

I couldn't find any use other than the definition, although it maybe
open coded somewhere.

> but
> it's possible that vm86 interacts with it (of that we accidentally lose
> some parts of EFLAGS in emulation).

Yeah, but I can't figure out why hybrid dom0 would change that...

Ian,

  reply	other threads:[~2012-05-04 10:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04  2:10 [hybrid]: unable to boot hvm due to eflags.ID Mukesh Rathor
2012-05-04  7:43 ` Jan Beulich
2012-05-04  9:08 ` Ian Campbell
2012-05-04 10:49   ` Tim Deegan
2012-05-04 10:53     ` Ian Campbell [this message]
2012-05-04 11:14       ` Tim Deegan
2012-05-04 11:19         ` Tim Deegan
2012-05-04 11:27         ` Jan Beulich
2012-05-04 18:19   ` Mukesh Rathor
2012-05-04 18:54     ` Mukesh Rathor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1336128807.2361.56.camel@zakaz.uk.xensource.com \
    --to=ian.campbell@citrix.com \
    --cc=Xen-devel@lists.xensource.com \
    --cc=tim@xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.