Re: [PATCH 3/8] KVM: Adds ability to preempt an executing VCPU

["Gregory Haskins" <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>]

>>> On Wed, May 16, 2007 at  6:05 AM, in message <464AD772.4050007-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote: 
> Gregory Haskins wrote:
>>   
>>> Later we'll have vcpu and thread_info point to each other and then you
>>> can do that kind of optimization.
>>>     
>>
>> I am not familiar with thread_info, but if it solves the dangling pointer 
> problem, that sounds great.
> 
> It's fairly tricky, but it's the right way forward.  It means a 1:1 
> association of a vcpu and a thread for the lifetime of the vcpu.

Any pointers would be appreciated.  Otherwise I will hit up google.

> 
>>   It sounds like you are in favor of leaving this optimization for a later 
> time.  As long as you are ok with every interrupt related ioctl such as 
> KVM_APIC_MSG, and KVM_ISA_INTERRUPT posting a signal to itself, we can pull 
> this for now.
> 
> Perhaps you can disable this by noticing that you're injecting an 
> interrupt now (another icky variable in struct kvm_vcpu).

I don't think this can be made to work without having the same problem that we face already.  Detecting self-injection is the same problem at ioctl entry point as it is at irqdevice::intr

> 
>>   Conversely, if the thread_info approach isn't hard, I would prefer to get 
> this right now, as the double interrupt thing seems nasty to me.
>>
>> Alternatively, perhaps I can just replace irq.task with irq.pid?  And I 
> could also replace irq.guest_mode with irq.guest_cpu.  I will then record the 
> pid where today I record the task.  Likewise, I can extract the guest_cpu 
> (using task_cpu(current)) where today I assign irq.guest_mode = 1.  That 
> would effectively remove the dangling pointer problem while retaining the 
> features that I like.  
>>   
> 
> pid can dangle just the same as a task pointer, only much worse.

I agree that it can dangle briefly if userspace is using something like thread-pooling to execute VCPUs.  I don't see how it can be worse, however.  And also note that having it dangling doesn't have the nasty problem that the task pointer does: dereferencing an invalid pointer.

However, that being said: I do see how either of these solutions leave a potential race condition against missing some signals:  If a thread that was executing the VCPU changes roles, AND it injects an interrupt before the new thread starts executing...we would miss the signal.  This is not a realistic scenario today, but it is a hole.  Hmmm..... how does that thread_info stuff work? ;)





-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/