qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] block: avoid SIGUSR2


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v2] block: avoid SIGUSR2
Date: Thu, 27 Oct 2011 16:32:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

Am 27.10.2011 16:15, schrieb Kevin Wolf:
> 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 <address@hidden>
>>>
>>> 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.

While trying out some more things, I added some fprintfs to
posix_aio_process_queue() and suddenly it also fails with the kill()
version. So what has changed might really just be the timing, and it
could be a race somewhere that has always (?) existed.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]