From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
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:49:02 +0100 [thread overview]
Message-ID: <20120504104902.GA6127@ocelot.phlegethon.org> (raw)
In-Reply-To: <1336122502.2361.7.camel@zakaz.uk.xensource.com>
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.
next prev parent reply other threads:[~2012-05-04 10:49 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 [this message]
2012-05-04 10:53 ` Ian Campbell
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=20120504104902.GA6127@ocelot.phlegethon.org \
--to=tim@xen.org \
--cc=Ian.Campbell@citrix.com \
--cc=Xen-devel@lists.xensource.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).