Avi Kivity wrote: > kvm doesn't do this directly. A hlt instruction (which is is used on > x86 to signal an idle cpu) is trapped and echoed to userspace, which > then sleeps using select(2). I've read that part. I still don't like this approach, it just does'nt fit our signal processor instruction without interresting race conditions. Our SIGP instruction does provide a condition code on the source cpu which indicates if the interprocessor signal was accepted by the target cpu. - When the target CPU is going idle, but has not yet called signal(), how can we figure from kernel space if it has masked this interrupt? We would want to figure that quick to be able to reenter VM context on the initiating CPU asap. - Also this requires synchronization, our arch requires there may be just one external interrupt pending per target CPU at a given time. How do we synchronize if both user and kernel can inject interrupts?
> We thought of having hlt sleep in the kernel, but that meant that we > would need to specify the exit conditions from sleep (signals, fd > readiness, aio readiness). Yes, that is required indeed. I think pending signals should make the syscall exit. AIO translates to SIGIO, and file descriptors should be checked by another pthread via poll. > (I think you're comparing to your pthread way of sleeping and waking, > just making sure we're all on the same page here) Yes we are. Sorry for confusion. 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
