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