From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36731 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oup2h-0001l6-5g for qemu-devel@nongnu.org; Sun, 12 Sep 2010 12:04:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oup2f-0005Vc-AP for qemu-devel@nongnu.org; Sun, 12 Sep 2010 12:04:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40375) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oup2f-0005VR-2s for qemu-devel@nongnu.org; Sun, 12 Sep 2010 12:04:33 -0400 Message-ID: <4C8CFA09.7090409@redhat.com> Date: Sun, 12 Sep 2010 18:04:25 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 3/3] disk: don't read from disk until the guest starts References: <1284213896-12705-1-git-send-email-aliguori@us.ibm.com> <1284213896-12705-4-git-send-email-aliguori@us.ibm.com> <4C8CAE9C.4030504@redhat.com> <4C8CD0DA.40401@codemonkey.ws> <4C8CD51B.8040602@redhat.com> <4C8CF1D3.6020506@codemonkey.ws> In-Reply-To: <4C8CF1D3.6020506@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Anthony Liguori , qemu-devel@nongnu.org, Stefan Hajnoczi , Juan Quintela On 09/12/2010 05:29 PM, Anthony Liguori wrote: > On 09/12/2010 08:26 AM, Avi Kivity wrote: >> On 09/12/2010 03:08 PM, Anthony Liguori wrote: >>>> This can cause a disk read, no? Shouldn't it be made asynchronous? >>> >>> >>> Yes, it should. I'm not sure there's an easy way to make it >>> asynchronous though not because of the block layer but because of >>> how these functions are called. >> >> Sorry to harp on the subject, but that's the standard problem with >> state machines. Every time you want to do a blocking operation in a >> function, you have to put all its locals in some structure, split the >> function into two, do some scheduling, etc. > > We can't block the VCPU thread for arbitrarily long periods of time. > If we get a PIO operation requesting information about geometry, we > can't wait for a disk read in order to satisfy that request. > > We need to kick off the I/O operations in the background such that the > data is available before the PIO operation happens. This isn't SM vs. > threads at all, this is simply about the fact that we can't do block > I/O during a PIO operation. Isn't this an identify command, where the guest can only read the data after the interface indicates it is ready (or posts an interrupt)? I thought the guest interface was already async. The code appears to support this: switch(val) { case WIN_IDENTIFY: if (s->bs && s->drive_kind != IDE_CD) { if (s->drive_kind != IDE_CFATA) ide_identify(s); else ide_cfata_identify(s); s->status = READY_STAT | SEEK_STAT; ide_transfer_start(s, s->io_buffer, 512, ide_transfer_stop); } else { if (s->drive_kind == IDE_CD) { ide_set_signature(s); } ide_abort_command(s); } ide_set_irq(s->bus); break; but I may be misinterpreting it. If I'm right, all we need to do is push this whole block to a thread. -- error compiling committee.c: too many arguments to function