RE: [Xen-devel] VMX Assist and x86 segment registers

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

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