Avi Kivity wrote:
> On 07/24/2009 10:00 AM, Jan Kiszka wrote:
>> Marcelo Tosatti wrote:
>>   
>>> On Wed, Jul 22, 2009 at 11:53:26PM +0200, Jan Kiszka wrote:
>>>     
>>>> Release and re-acquire preemption and IRQ lock in the same order as
>>>> vcpu_enter_guest does.
>>>>        
>>> This should happen in vcpu_enter_guest, before it decides to disable
>>> preemption/irqs (so you consolidate the control there).
>>>      
>>
>> Maybe, maybe not. handle_invalid_guest_state is an alternative way of
>> "executing" guest code, and it currently shares the setup and tear-down
>> with vmx_vcpu_run. If it has to share parts that actually require
>> preemption and IRQ lock, then moving makes not much sense. Can anyone
>> comment on what the requirements for handle_invalid_guest_state are?
>>    
> 
> Like you said, it's an alternative to vmx entry/exit, so it shares the
> same requirements.  It must run with interrupts and preemption enabled,
> but any code that normally runs in the entry critical section (like
> interrupt injection) must continue to run in a critical section.
> 
> 
>> I would suggest to merge this fix first and then decide about and
>> potentially merge a refactoring patch.
>>    
> 
> btw, what does it fix?  a debug warning?
> 

I haven't seen anything in the wild, and I don't think it would raise a
warning. All it should cause is a potential delay of some pending
reschedule as preempt_enable will not fire under local_irq_disable.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to