From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpUZl-0001Qy-CN for qemu-devel@nongnu.org; Thu, 12 Jul 2012 21:21:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SpUZk-0003nw-3b for qemu-devel@nongnu.org; Thu, 12 Jul 2012 21:21:45 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:50577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpUZj-0003ns-T5 for qemu-devel@nongnu.org; Thu, 12 Jul 2012 21:21:44 -0400 Received: by bkcji1 with SMTP id ji1so2278816bkc.4 for ; Thu, 12 Jul 2012 18:21:42 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1340347459-29861-1-git-send-email-peter.crosthwaite@petalogix.com> <4FED6638.90703@redhat.com> <4FF16407.6030703@redhat.com> <4FF17178.406@redhat.com> Date: Fri, 13 Jul 2012 11:21:41 +1000 Message-ID: From: Peter Crosthwaite Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Peter Maydell , stefanha@linux.vnet.ibm.com, Stefan Hajnoczi , qemu-devel@nongnu.org, edgar.iglesias@gmail.com, john.williams@petalogix.com On Thu, Jul 12, 2012 at 11:42 PM, Markus Armbruster wrote: > Kevin Wolf writes: > >> Am 02.07.2012 11:42, schrieb Peter Crosthwaite: >>> On Mon, Jul 2, 2012 at 7:04 PM, Kevin Wolf wrote: >>>> Am 02.07.2012 10:57, schrieb Peter Crosthwaite: >>>>> No conditional on the qemu_coroutine_create. So it will always create >>>>> a new coroutine for its work which will solve my problem. All I need >>>>> to do is pump events once at the end of machine model creation. Any my >>>>> coroutines will never yield or get queued by block/AIO. Sound like a >>>>> solution? >>>> >>>> If you don't need the read data in your initialisation code, >>> >>> definately not :) Just as long as the read data is there by the time >>> the machine goes live. Whats the current policy with bdrv_read()ing >>> from init functions anyway? Several devices in qemu have init >>> functions that read the entire storage into a buffer (then the guest >>> just talks to the buffer rather than the backing store). >> >> Reading from block devices during device initialisation breaks >> migration, so I'd like to see it go away wherever possible. Reading in >> the whole image file doesn't sound like something for which a good >> excuse exists, you can do that as well during the first access. > > I just stumbled over another problem case: encrypted images. > > Encrypted images specified on the command line get their keys from the > monitor. -S is forced automatically. You can then use block_passwd to > set keys. cont asks for keys still missing. > > However, device initialization happens *before* you get access to the > monitor. Therefore, your init method runs without a key. > > It would be nice if the monitor was available before device > initialization. Patches welcome. > Hi Markus, I consolidated this discussion into a new RFC which proposes a few solutions the the bdrv_read() from init() problem. http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg00237.html Are you able to comment on those ideas WRT your latest thoughts? Regards, Peter > [...]