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: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2] block: avoid SIGUSR2
Date: Fri, 28 Oct 2011 17:58:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1

On 10/28/2011 02:31 PM, Stefan Hajnoczi wrote:
Zhi Yong: We were just talking about converting devices to aio.  If
you have time to do that for fdc, sd, or any other synchronous API
users in hw/ that would be helpful.  Please let us know which device
you are refactoring so we don't duplicate work.

The problem is not really fdc or sd themselves, but whoever uses the result of the synchronous reads---respectively DMA and the SD clients.

Some SD clients talk to the SD card in a relatively confined way and have interrupts that they set when the operation is done, so these confined parts that talk to the card could be changed to a coroutine and locked with a CoMutex. However, not even all of these can do it (in particular I'm not sure about ssi-sd.c cannot).

I'm thinking that the problem with the floppy is really that it mixes synchronous and asynchronous parts. As long as you're entirely synchronous you should not have any problem, but as soon as you add asynchronicity (via bottom halves) you now have to deal with reentrancy.

"git grep _bh hw/" suggests that this should not be a huge problem; most if not all occurrences are related to ptimers, or are in entirely asynchronous code (IDE, SCSI, virtio). Floppy+DMA seems to be the only problematic occurrence, and any fix (switch to timers, drop idle BH in qemu_aio_wait, reschedule if DMA reenters during I/O, drop BH completely and just loop) is as good as the others.

(Actually, another one worth checking is ATAPI, but I don't know the code and the standards well enough).

Paolo



reply via email to

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