Gregory Haskins wrote: >>>> 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. > >
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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
