From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40370 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OuoV8-0001cv-9e for qemu-devel@nongnu.org; Sun, 12 Sep 2010 11:29:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OuoUg-0007QZ-Gp for qemu-devel@nongnu.org; Sun, 12 Sep 2010 11:29:50 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:41105) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OuoUg-0007QO-EV for qemu-devel@nongnu.org; Sun, 12 Sep 2010 11:29:26 -0400 Received: by yxs7 with SMTP id 7so2064989yxs.4 for ; Sun, 12 Sep 2010 08:29:26 -0700 (PDT) Message-ID: <4C8CF1D3.6020506@codemonkey.ws> Date: Sun, 12 Sep 2010 10:29:23 -0500 From: Anthony Liguori 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> In-Reply-To: <4C8CD51B.8040602@redhat.com> 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: Avi Kivity Cc: Kevin Wolf , Anthony Liguori , qemu-devel@nongnu.org, Stefan Hajnoczi , Juan Quintela 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. >>> >>> Or just move it to just before the guest starts? >> >> We don't really have a notion of "guest starts" today although maybe >> we should. > > Wasn't there some qdev callback that represents this? Faint memory > from the reset thread. Yes, realize(). I guess that's a reasonable approach. Regards, Anthony Liguori