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

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Gregory Haskins wrote:
>>>> 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.
>
>   

task_struct (include/linux/sched.h) is probably a better fit.  
Basically, like each task has attributes like its registers, fpu state, 
and open file table, it would also have a vcpu attribute if it's part of 
a virtual machine.

>>>   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
>   

Ok.
>   
>>>   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? ;)
>   

These corner cases don't need to work well as VMs, they just need not to 
be expoitable.


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


-------------------------------------------------------------------------
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/