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