From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKhLM-0005YV-16 for qemu-devel@nongnu.org; Sun, 30 Oct 2011 22:11:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKhLK-0005x3-AU for qemu-devel@nongnu.org; Sun, 30 Oct 2011 22:11:19 -0400 Received: from e23smtp01.au.ibm.com ([202.81.31.143]:54828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKhLJ-0005wr-Mx for qemu-devel@nongnu.org; Sun, 30 Oct 2011 22:11:18 -0400 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp01.au.ibm.com (8.14.4/8.13.1) with ESMTP id p9V29M1K002326 for ; Mon, 31 Oct 2011 13:09:22 +1100 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p9V28H9Z1339394 for ; Mon, 31 Oct 2011 13:08:18 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p9V2B5eS002313 for ; Mon, 31 Oct 2011 13:11:05 +1100 Date: Mon, 31 Oct 2011 10:10:08 +0800 From: Zhi Yong Wu Message-ID: <20111031021008.GA20321@f15.cn.ibm.com> References: <1316443033-6489-1-git-send-email-freddy77@gmail.com> <4EA95BFF.6070807@redhat.com> <20111027135731.GA21052@stefanha-thinkpad.localdomain> <4EA96776.6020807@redhat.com> <4EA96B82.6070507@redhat.com> <4EAA9310.2030705@redhat.com> <4EAA9700.6030605@redhat.com> <4EAAA025.100@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v2] block: avoid SIGUSR2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Lucas Meneghel Rodrigues , Kevin Wolf , aliguori@us.ibm.com, Stefan Hajnoczi , qemu-devel@nongnu.org, Frediano Ziglio , Cleber Rosa , Paolo Bonzini On Fri, Oct 28, 2011 at 01:31:20PM +0100, Stefan Hajnoczi wrote: >Subject: Re: [Qemu-devel] [PATCH v2] block: avoid SIGUSR2 >From: Stefan Hajnoczi >To: Zhi Yong Wu >Cc: Paolo Bonzini , Lucas Meneghel Rodrigues > , aliguori@us.ibm.com, Stefan Hajnoczi > , qemu-devel@nongnu.org, Frediano Ziglio > , Cleber Rosa , Kevin Wolf > >Content-Type: text/plain; charset=ISO-8859-1 >x-cbid: 11102812-3534-0000-0000-000000FD91EE >X-IBM-ISS-SpamDetectors: Score=0; BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; > SC=0; ST=0; TS=0; UL=0; ISC= >X-IBM-ISS-DetailInfo: BY=3.00000227; HX=3.00000175; KW=3.00000007; > PH=3.00000001; SC=3.00000001; SDB=6.00082671; UDB=6.00022873; > UTC=2011-10-28 12:31:35 >X-Xagent-From: stefanha@gmail.com >X-Xagent-To: wuzhy@linux.vnet.ibm.com >X-Xagent-Gateway: vmsdvm6.vnet.ibm.com (XAGENTU8 at VMSDVM6) > >On Fri, Oct 28, 2011 at 1:29 PM, Kevin Wolf wrote: >> Am 28.10.2011 13:50, schrieb Paolo Bonzini: >>> On 10/28/2011 01:33 PM, Kevin Wolf wrote: >>>> I'm afraid that we can only avoid things like this reliably if we >>>> convert all devices to be direct users of AIO/coroutines. The current >>>> block layer infrastructure doesn't emulate the behaviour of bdrv_read >>>> accurately as bottom halves can be run in the nested main loop. >>>> >>>> For floppy, the following seems to be a quick fix (Lucas, Cleber, does >>>> this solve your problems?), though it's not very satisfying. And I'm not >>>> quite sure yet why it doesn't always happen with kill() in >>>> posix-aio-compat.c. >>> >>> Another "fix" is to change idle bottom halves (at least the one in >>> hw/dma.c) to 10ms timers. >> >> Which would be using the fact that timers are only executed in the real >> main loop. Which makes me wonder if it would be enough for floppy if we >> changed qemu_bh_poll() to take a bool run_idle_bhs that would be true in >> the main loop and false an qemu_aio_wait(). >> >> Still this wouldn't be a general solution as normal BHs have the very >> same problem if they are scheduled before a bdrv_read/write call. To >> solve that I guess we'd have to reintroduce AsyncContext, but it has its >> own problems and was removed for a reason. >> >> Or we make some serious effort now to convert devices to AIO. > >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. Stefan, I am working on flash(onenand, CFI), cdrom, sd, fdc, etc. If anyone has good thought, pls let me know.:) Regards, Zhi Yong Wu > >Stefan >