"Kevin P. Lawton" <[EMAIL PROTECTED]> wrote:
> Then why not do the same for guest OS code, since it's
> also running at ring3? We have to look at a few issues
> here. The most obvious one is that the RPL (lower
> bits) of the selector define the privilege level,
> and if you're running in the wrong privilege
> level, a "PUSH CS; POP EAX" will see this difference.
B.t.w. is it possible to actually let the guest load a
segment register with RPL 0 (but the *DPL* still remains 3)?
I'm aware that this won't work for CS and SS, but for the
data segment registers it could work ... This way, we
wouldn't need to virtualize data segment register accesses
at least.
> Note that Intel did add a feature called Protected-mode
> Virtual Interrupts (PVI) to the Pentium (and SL enhanced 486),
> which if designed correctly, may be of help in virtualizing IF
> in guest OS code. This is currently perhaps *the* most
> undocumented x86 feature. It's not clear to me whether
> we can use this, as I haven't dug into it enough.
Well, the corresponding extensions to v86 mode (VME) appear
to handle this correctly: if VME is on, PUSHF places the VIF
bit into the IF slot (and POPF reverses that) ... This is at
least what Collins' article in the DDJ says.
On the other hand, if VME is on, PUSHF replaces the IOPL
in the EFLAGS stack image always with 3, so while the guest
thinks it is running with IOPL != 3 we'll need to virtualize
PUSHF anyway :-/
Yet another thing to consider is that the guest OS might want
to *use* the PVI and/or VME modes itself ;-) Especially in the
case of Windows as guest this is rather likely, as those modes
were basically *designed* for Windows ... We might of course
try to fool the processor detection routines of the guest to
think it's running on an 386 (or 486), but I'm not sure this
is a good idea.
Bye,
Ulrich
