>>> On Wed, May 16, 2007 at 6:05 AM, in message <[EMAIL PROTECTED]>, Avi Kivity <[EMAIL PROTECTED]> 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
