From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: VMX Assist and x86 segment registers Date: Wed, 31 May 2006 14:31:03 -0500 Message-ID: <447DEEF7.7070708@us.ibm.com> References: <87591F96-1ED2-4A88-9A0F-B8297B50814A@netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <87591F96-1ED2-4A88-9A0F-B8297B50814A@netapp.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Randy Thelen Cc: xen-devel List-Id: xen-devel@lists.xenproject.org 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. 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@lists.xensource.com > http://lists.xensource.com/xen-devel