Am 27.10.2011 15:57, schrieb Stefan Hajnoczi: > On Thu, Oct 27, 2011 at 03:26:23PM +0200, Kevin Wolf wrote: >> Am 19.09.2011 16:37, schrieb Frediano Ziglio: >>> Now that iothread is always compiled sending a signal seems only an >>> additional step. This patch also avoid writing to two pipe (one from signal >>> and one in qemu_service_io). >>> >>> Work with kvm enabled or disabled. strace output is more readable (less >>> syscalls). >>> >>> Signed-off-by: Frediano Ziglio <fredd...@gmail.com> >> >> Something in this change has bad effects, in the sense that it seems to >> break bdrv_read_em. > > How does it break bdrv_read_em? Are you seeing QEMU hung with 100% CPU > utilization or deadlocked?
Sorry, I should have been more detailed here. No, it's nothing obvious, it must be some subtle side effect. The result of bdrv_read_em itself seems to be correct (return value and checksum of the read buffer). However instead of booting into the DOS setup I only get an error message "Kein System oder Laufwerksfehler" (don't know how it reads in English DOS versions), which seems to be produced by the boot sector. I excluded all of the minor changes, so I'm sure that it's caused by the switch from kill() to a direct call of the function that writes into the pipe. > One interesting thing is that qemu_aio_wait() does not release the QEMU > mutex, so we cannot write to a pipe with the mutex held and then spin > waiting for the iothread to do work for us. > > Exactly how kill and qemu_notify_event() were different I'm not sure > right now but it could be a factor. This would cause a hang, right? Then it isn't what I'm seeing. Kevin