Carsten Otte wrote: > Avi Kivity wrote: >> Carsten Otte wrote: >>> No, we did not have the need to do that. Now that you mention it, >>> we'd want to move interprocessor signal handling into the kernel >>> anyway for performance reasons. That would rise the need to wake up >>> from kernel. The other way round, how do you intend to wake a thread >>> that uses poll() or similar from userspace? >>> >> >> Write to a pipe, or send a signal (signals are quite fast if you mask >> them in userspace and use ppoll()). > Signals have the disadvantage that they wake all guest CPUs (unless > one dedicates a singal per vcpu which does'nt scale). I think we need > a wakeup mechanism that can be used to send an interrupt to a specific > idle cpu from both kernel and userland.
You can send a signal to a specific thread. See tkill(2). > Pipes and poll (one per cpu) would allow that, but it seems to me like > there must be better options. > After having slept over it, I think that our idle/wakeup mechanism for > s390host is a mess. I will try to come up with an idea for this. 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. Having an fd will also simplify the kernel/userspace communication area setup (current kvm does a similar thing). > > Also, I am going to figure why kvm does'nt to run non-root in my local > x86 installation. > chmod 0666 /dev/kvm should be enough, if you don't use bridged networking. (the long way is to add a kvm group, add yourself to that, and add a udev rule setting /dev/kvm's group to kvm). -- 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
