Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator

[Avi Kivity <avi@redhat.com>]

On 07/12/2010 03:36 PM, Mohammed Gamal wrote:
> On Mon, Jul 12, 2010 at 9:26 AM, Avi Kivity<avi@redhat.com>  wrote:
>    
>> On 07/12/2010 01:56 AM, Mohammed Gamal wrote:
>>      
>>> fter some conversation with Avi concerning why unreal mode has been seen
>>> to work
>>> with KVM on Intel. It clears out the scenario is caused as follows:
>>>
>>> - guest enters big real mode
>>> - kvm squashes limit to 64k-1
>>> - guest executes instructions with offset>    64k
>>> - cpu issues #GP due to limit violation
>>> - kvm handle_rmode_exception() ->    emulator
>>> - emulator ignores limit, emulates instruction
>>>
>>> With these applied I am getting vmentry failures with SeaBIOS and
>>> gPXE. I could still get SeaBIOS to work with
>>> emulate_invalid_guest_state=1.
>>> So it's needless to say that these patches are not meant for merging!
>>>
>>>        
>> Well, eventually you need to fix this.
>>      
> What happens is that guests are switched to big real mode so either
> gPXE and SeaBIOS need to be modified to work with the way KVM handles
> segment limits when switching to real mode, but that'd be only a
> temporary solution. The other - and better IMO - option is to get
> e_i_g_s=1 completely functional, which is something we want to do
> anyway. So we can address all the comments you have on these patches
> and eventually merge them along with the rest of e_i_g_s patches.
>    

Does SeaBIOS use big real mode now?

I think this can work even with e_i_g_s=0.  Simply return 
vmx->rmode.seg.limit instead of GUEST_seg_LIMIT.  In fact we need to do 
this anyway, so live migration migrates the correct limit, not the hack 
that we do for vmx.

>>> --------
>>>
>>> Changes from v2:
>>> - Addeded generic segment limit check helpers
>>> - Removed individual segment register segment helpers as they're no longer
>>> needed
>>>
>>>
>>>        
>> What about the rest of my comments?
>>      
> I did change the limit calculations to avoid overflows, and
> re-arranged patches as per your suggestion. Sorry for not pointing
> this out in the change log. Check the patches I sent out for details.
>    

What about expand-down segments?  and moving the limit check where the 
access is emulated (so we are sure we don't miss a check)?

-- 
error compiling committee.c: too many arguments to function