Re: VMX Assist and x86 segment registers

[Anthony Liguori <aliguori@us.ibm.com>]

Petersson, Mats wrote:
>  
>
>   
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com 
>> [mailto:xen-devel-bounces@lists.xensource.com] 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@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>       
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>>     
>
>