Re: Questions on the VMentry failure patch

[Avi Kivity <avi@qumranet.com>]

Mohammed Gamal wrote:
> On Thu, Jul 10, 2008 at 4:48 PM, Mohammed Gamal <m.gamal005@gmail.com> wrote:
>   
>>>>  It's true indeed, the patch did increase the likelihood of the
>>>> problem with me (although it occurs every few runs). I modified
>>>> invalid_guest_state() to call kvm_report_emulation_failure() in all
>>>> cases and I noticed that whenever the crash happens it happens here:
>>>>
>>>> rip 6e10 66 b8 20 00
>>>>
>>>> It's too late at night here, so I'll not lookup the opcode map now :)
>>>> . I'll further look into it later.
>>>>
>>>>         
>>> Another thing, I tried -no-kvm-pit switch and it tremendously increase
>>> the likelihood of the crash to almost a 100%.
>>>
>>>       
>> I updated to the latest kvm-userspace git tree, and now the failure is
>> happening at completely random instructions whether or not we are
>> using -no-kvm-pit.
>>
>>     
>
> I didn't have the gfxboot source code in hand, but now that I've got
> it. It clears out that the failure always occurs in the
> switch_to_pm_20 routine. However, the failure doesn't happen at one
> particular instruction, but either doesn't happen at all or happens at
> any instruction between addresses 6e10 and 6e27.
>
> I'm suspecting it might be some kind of a race condition, although I
> don't see where in the code - kernel side to specific - that this race
> exactly might occur. Maybe the locking changes in the userspace side
> helped some underlying issue to come up to the surface just like what
> happened with FreeDOS. I'll look further into it, any
> pointers/help/suggestions are appreciated.
>   

I suspected an interrupt, which fits the scenario you describe.  
Although Anthony tested this and found out interrupts were not involved, 
IIRC.

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