[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Randy Thelen" <rthelen@xxxxxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Wed, 31 May 2006 19:16:31 +0200
  • Delivery-date: Wed, 31 May 2006 10:15:14 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcaE1SBotx/O1u1uTU+o8/INcO251wAAGv3w
  • Thread-topic: [Xen-devel] VMX Assist and x86 segment registers

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Randy Thelen
> Sent: 31 May 2006 18:08
> To: xen-devel
> Subject: Re: [Xen-devel] VMX Assist and x86 segment registers
> 
> 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.
> 
> 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.

Whilst what I'm working on at the moment isn't going to solve this
particular problem, it should help getting the information in to/out of
QEMU, as I'm working on putting the x86_emulate.c that is currently used
for parts of instruction emulation in Xen, into QEMU. The next step of
that process would be to add proper support for segment registers
(today, x86_emulate.c doesn't cope well with segments that doesn't have
a base-address of zero, which causes certain OS's to crash - I think
some BSD-version, and I know Minix does this). 

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.