Re: Questions on the VMentry failure patch

[Anthony Liguori <anthony@codemonkey.ws>]

Avi Kivity wrote:
> 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.

It was at least not occurring for me when an interrupt was being 
injected.  That's not to say that it isn't somehow affected by interrupt 
injections but it doesn't appear to be the obvious interrupt occurs 
while doing switch_to_pm_20.

Regards,

Anthony Liguori