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

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

>>> On Tue, May 15, 2007 at  3:28 AM, in message <46496125.5020909-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote: 
> Gregory Haskins wrote:
>
>>
>> I like having both states tracked, because it allows me to optimize the vcpu 
> interrupt if the context of the injection is the same as the execution.  E.g. 
> if the single QEMU thread calls KVM_RUN and then KVM_INTERRUPT, I can skip 
> sending an eventfd because I know the irq.task == current and its pointless.  
> 
>>   
> 
> You can't rely on irq.task if !guest_mode.  Under the current design,
> the task may have exited and you'd be dereferencing unallocated memory. 
> While it won't oops or cause anything bad to happen (and current qemu
> can't trigger this), it isn't nice.

Hmm...that is a good point.

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

Thoughts?

> 
> Oh, and nobody said that the task waiting on the event is the same as
> the task running the vcpu.

I'm a little confused by this statement.  I don't use irq.task for assigning a target for the event.  That is all self contained in the eventfd.  Its true that some of the older designs used this as the send_sig() target, but the assumption there was we were posting a signal to the entire PID, not a specific TID.  That could have been a bad assumption, but its moot now.  Let me know if you meant something else.

> 
>> (Note that in the original designs, irq.task was also used to designate a 
> target for send_sig.  Perhaps it is no longer logical to have this scoped to 
> the vcpu.irq structure anymore?  E.g. should I make it vcpu.task?)
>>   
> 
> I think so.
> 
> 

Ok.  Assuming you accept my pid/guest_cpu idea above, I will make it "pid_t vcpu.owner", and "int vcpu.irq.guest_cpu" (where it will be -1 if not in guest_mode)




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