Avi Kivity wrote: > If the eventfd patchset is merged, then file descriptors will become the > standard Linux handle type, and poll (or rather, epoll) will become the > standard way of waiting for something to happen. But of course if you > come up with something better we'll use that. Triggered by this discussion, I have spent quite some time thinking about signaling, idle cpus, interrupts, signal processor (read: IPI) and such lately. It has become clear to me, that sleeping in userspace has been a bad design point I've made. The way kvm deals with this (idle cpu thread sleeps interruptible in kernel) is clearly preferable.
Our sie system call has quite a complex userspace interface that allows the user to modify various bits and pieces of our virtual cpu control block. All this is needed only, because we do a lot of wrong things in userspace. Like signal processor (read: IPI). I will go ahead and put these things into our kernel module. That should simplify our user<->kernel interface a lot. One problem is, that we need to inject interrupts from userland. This requires waking up idle CPUs. I want to try how it comes out with a new system call for irqs rather then using tkill(). We could have the kernel choose the vcpu that is enabled for this interrupt for example. And the kernel can do optimizations like sending irqs to idle cpus preferably. The user could supply a CPU mask that specifies what CPUs come into question for the irq. Another neat advantage of moving SIE specifics into the kernel module is, that our userspace will be left with device drivers only. We can then put those into kvm/qemu or switch to other paravirtual device drivers and discard our userspace code. I believe once we've changed that, merging with kvm on both kernel and user side should become easier then it is today. so long, Carsten ------------------------------------------------------------------------- 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
