On Tue, Jun 16, 2009 at 12:17:22PM -0400, Gregory Haskins wrote: > > Maybe I misunderstand what iosignalfd is - isn't it true that you get eventfd > > and kvm will signal that when guest performs io write to a specific > > address, and then drivers can get eventfd and poll it to detect > > these writes? > > > > Correct. > > > If yes, you have no way to know that the other end of eventfd > > is connected to kvm, so you don't know you can access current->mm. > > > > Well, my intended use for them *does* know its connected to KVM. How does it know? You get a file descriptor and you even figure out it's an eventfd. Now what? Any process can write there. > Perhaps there will be others that do not in the future, but like I said > it could be addressed as those actually arise. > > > > > >> So since I cannot use it accurately for the hardirq/threaded-irq type > >> case, and I don't actually need it for the iosignalfd case, I am not > >> sure its the right direction (at least for now). I do think it might > >> have merit for syscal/vmexit uses outside of iosignalfd, but I do not > >> see a current use-case for it so perhaps it can wait until one arises. > >> > >> -Greg > >> > > > > But, it addresses the CONFIG_PREEMPT off case, which your design doesn't > > seem to. > > > > Well, the problem is that it only addresses it partially in a limited > set of circumstances, and doesn't address the broader problem. I'll > give you an example: > > (First off, lets assume that we are not going to have > eventfd_signal_task(), but rather eventfd_signal() with two option > flags: EVENTFD_SIGNAL_CANSLEEP, and EVENTFD_SIGNAL_CURRENTVALID > > Today vbus-enet has a rx-thread and a tx-thread at least partially > because I need process-context to do the copy_to_user(other->mm) type > stuff (and we will need similar for our virtio-net backend as well). I > also utilize irqfd to do interrupt injection. Now, since I know that I > have kthread_context, I could modify vbus-enet to inject interrupts with > EVENTFD_SIGNAL_CANSLEEP set, and this is fine. I know that is safe. > > However, the problem is above that! I would like to optimize out the > tx-thread to begin with with a similar "can_sleep()" pattern whenever > possible. > > For instance, if the netif stack calls me to do a transmit and it > happens to be in a sleepable context, it would be nice to just skip > waking up the tx-thread. I would therefore just do the > copy_to_user(other->mm) + irqfd directly in the netif callback, thereby > skipping the context switch. What do you mean by copy_to_user(other->mm) here? If you are going to switch to another mm, then I think current->mm must be valid (I think it's not enough that you can sleep). So preemptible() might not be enough. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
