|
xen-devel
Re: [Xen-devel] VMX Assist and x86 segment registers
Petersson, Mats wrote:
-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Anthony Liguori
Sent: 31 May 2006 20:31
To: Randy Thelen
Cc: xen-devel
Subject: Re: [Xen-devel] VMX Assist and x86 segment registers
Randy Thelen wrote:
Khoa Huynh wrote:
Yes, we are thinking of putting a full instruction emulator into
qemu-dm and emulating 16-bit stuff in qemu-dm instead of using
vmxassist (vmxassist will go away). Leendert van Doorn and I are
working on this. Thanks.
The problem, as I see it, is the hand-off of the "hidden" or
"invisible" segmentation register information during the transition
from emulator to the real hardware and vice-versa. So,
regardless of
whether qemu-dm is emulating the 16 bit code or vmxassist,
the correct
segment information has to be conveyed for correct execution.
vmxassist is the source of the problem here though as it uses
vm86 mode which means that there is no way to get at the
hidden cpu state. If we moved to a model where all 16-bit
code was emulated by qemu, we would have access to all the
hidden cpu state.
There are fewer problems in 32 bit mode since the
segmentation stuff is mostly visible so there shouldn't be a
problem in handing off from the
16 bit emulator to to direct 32 bit execution.
Yes, that's correct - except that most of the code in Xen that handles
instruction emulation (for example handling MMIO to QEMU and the
Page-table-write code) assumes that if the processor is in protected
mode, the register base is zero. This works for most parts in Linux and
Windows [nearly always in both those OS's are the base address zero -
and unless the programmer jumps through hoops, it would be for cases
where we need to emulate instructions]. However, there are some other
OS's that actually DO USE segmentation to prevent memory blocks from
leaking into each other, etc. Not to mention that there are plenty of
boot-loaders, BIOS interface-code [for OS's that support legacy devices
by calling to the BIOS instead of writing a dedicated driver,
particularly during boot/installation] and such that do have
"interesting" code in them, either using real-mode segments in protected
mode, or "big real-mode", i.e. setting up a segment that is base=0,
limit=4GB in prot.mode and then using it in real-mode.
For AMD it's a little bit easier, since we support "paged real-mode", so
we don't need to mess about with VM86 and supporting strange things like
this.
But for all architectures, the code that currently emulates MMIO
instructions is broken with regards to big real-mode and protected mode
where base != 0.
Even QEMU doesn't fully implement proper segmentation semantics. For
instance, it doesn't enforce segment limits IIRC.
We should be careful when we do get around to making the switch over and
make sure we don't enable code to do things it shouldn't do.
Regards,
Anthony Liguori
--
Mats
Regards,
Anthony Liguori
The example of big real mode that I included in my mail was
simply to
note the fact that segment data is persistent across mode
changes and
vmxassist does not carry that information forward to
protected mode or
backward to real mode.
The example code snippet which is relevant here is:
---------bits: 16---------filename: btx.o---------origin:
00009010---------
00009010 (01) fa CLI
00009011 (02) 31c0 XOR AX, AX
00009013 (02) 8ed0 MOV SS, AX
00009015 (03) bc 0018 MOV SP, 0x1800
00009018 (02) 8ec0 MOV ES, AX
0000901a (02) 8ed8 MOV DS, AX
At this point DS is zero'd.
00009070 (03) 0f20c0 MOV EAX, CR0
00009073 (04) 66 83c8 01 OR EAX, 0x1
00009077 (03) 0f22c0 MOV CR0, EAX
0000907a (05) ea 7f00 0800 JMP FAR 0x8:0x7f
The far jump gets us to 32 bit mode:
---------bits: 32---------filename: btx.o---------origin:
0000907f---------
0000907f (02) 31c9 XOR ECX, ECX
00009081 (02) b1 10 MOV CL, 0x10
00009083 (02) 8ed1 MOV SS, CX
00009085 (02) b1 38 MOV CL, 0x38
00009087 (03) 0f00d9 LTR CX
...
000090ac (06) ff35 0c000000 PUSH DWORD [0xc]
At the point of 90ac, the DS segment is 0. vmxassist was
setting the
'hidden' fields of the segment register such that ds was being
interpreted as a null segment. But it's not null, it's valid.
Qemu-dm will need to address this code snippet, too.
-- Randy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home