Il 05/03/2012 16:14, Avi Kivity ha scritto: >> > Hmm, I don't think so. It would need to protect execution of the >> > iohandlers too, and pretty much everything can happen there including a >> > nested loop. Of course recursive mutexes exist, but it sounds like too >> > big an axe. > The I/O handlers would still use the qemu mutex, no? we'd just protect > the select() (taking the mutex from before releasing the global lock, > and reacquiring it afterwards). Yes, that could work, but it is _really_ ugly. I still prefer this patch or fixing NBD. At least both contain the hack in a single place. >> > I could add a generation count updated by qemu_aio_wait(), and rerun the >> > select() only if the generation count changes during its execution. >> > >> > Or we can call it an NBD bug. I'm not against that, but it seemed to me >> > that the problem is more general. > What about making sure all callers of qemu_aio_wait() run from > coroutines (or threads)? Then they just ask the main thread to wake > them up, instead of dispatching completions themselves. That would open another Pandora's box. The point of having a separate main loop is that only AIO can happen during qemu_aio_wait() or qemu_aio_flush(). In particular you don't want the monitor to process input while you're running another monitor command. Paolo -- 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
