Re: [PATCH] gfxboot VMX workaround v2

[Anthony Liguori <anthony@codemonkey.ws>]

Alexander Graf wrote:
>
> On Apr 7, 2008, at 6:51 PM, Anthony Liguori wrote:
>
>> Alexander Graf wrote:
>>>
>>> On Apr 7, 2008, at 6:05 PM, Anthony Liguori wrote:
>>>
>>>> Alexander Graf wrote:
>>>>> Hi,
>>>>>
>>>>> this is an improved version of the patch I sent several weeks ago to
>>>>> this list. Functionally nothing changed; it still hacks into 
>>>>> gfxboot and
>>>>> patches it to work on Intel CPUs on the fly. The big difference is 
>>>>> that
>>>>> this version is cleaned up and should work with every future CPU 
>>>>> available.
>>>>>
>>>>> Please do _not_ apply this patch. I send it to the list only for
>>>>> interested people, who would like to have a working version of KVM 
>>>>> for
>>>>> their systems right now. It is neither a proper fix nor the right
>>>>> approach to deal with this issue. It is merely a hack that works 
>>>>> for me
>>>>> and maybe for others too.
>>>>>
>>>>
>>>> Perhaps a viable way to fix this upstream would be to catch the 
>>>> vmentry failure, look to see if SS.CPL != CS.CPL, and if so, invoke 
>>>> x86_emulate() in a loop until SS.CPL == CS.CPL.
>>>>
>>>> There are very few instructions in gfxboot that would need to be 
>>>> added to x86_emulate (if they aren't already there).
>>>
>>> In a previous thread Avi already explained a quite reasonable way to 
>>> approach this problem, which I believe is a really good approach. He 
>>> wanted to x86_emulate until the environment is "VMX friendly" again, 
>>> thus resolving big real mode problems as well.
>>
>> I've got a slightly lamer approach than what Avi probably wants.  I 
>> lost interest in updating x86_emulate once I realized how far xen's 
>> copy has gotten.  To get GFXBOOT 3.3.28 working just requires adding 
>> far jmp to x86_emulate.  The sequence should look like:
>>
>>       jmp pm_seg.prog_c32:switch_to_pm_20
>> switch_to_pm_20:
>>
>>       bits 32
>>
>>       mov ax,pm_seg.prog_d16
>>       mov ds,ax
>>       mov eax,ss
>>
>> Which means we'll get 3 vmentry failures.  The two moves should 
>> already be supported by x86_emulate but I haven't confirmed.  It's 
>> not a complete solution to our real mode woes but I think it's a 
>> reasonable first step.
>
> Right, this was exactly the approach I wanted to go at first. I just 
> backed off it as I saw how much ljmp actually does, as normal x86 CPUs 
> switch to PM not on cr0 setting, but on the ljmp after that.
>
> So is that simple implementation you have written actually doing the 
> right thing?

Yes, but it won't compile as KVM does not have a proper load_seg() 
function like the Xen's x86_emulate.  I started copying stuff in but ran 
against some additional ops (like ->read_segment).  I don't think it 
will be very hard to implement but it exceeded the 45 seconds I was 
willing to spend looking at it :-)

Regards,

Anthony Liguori

> Regards,
>
> Alex
>
>>
>>
>> Regards,
>>
>> Anthony Liguori
>>> I personally agree that the real approach is way superior to my 
>>> patch. I just won't have the time to do it in the near future and 
>>> not being able to boot intuitively hurts KVM users unnecessarily ;-).
>>>
>>> Regards,
>>>
>>> Alex
>>
>> <x86_emulate.patch>
>


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone