From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SleQX-0007oY-42 for qemu-devel@nongnu.org; Mon, 02 Jul 2012 07:04:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SleQT-0002NR-Ev for qemu-devel@nongnu.org; Mon, 02 Jul 2012 07:04:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SleQT-0002NE-78 for qemu-devel@nongnu.org; Mon, 02 Jul 2012 07:04:17 -0400 Message-ID: <4FF18028.7010302@redhat.com> Date: Mon, 02 Jul 2012 13:04:08 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1340347459-29861-1-git-send-email-peter.crosthwaite@petalogix.com> <4FED6638.90703@redhat.com> <4FF16407.6030703@redhat.com> <4FF17178.406@redhat.com> <4FF17D74.7040309@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , stefanha@linux.vnet.ibm.com, Stefan Hajnoczi , qemu-devel@nongnu.org, Markus Armbruster , edgar.iglesias@gmail.com, john.williams@petalogix.com Am 02.07.2012 12:57, schrieb Peter Crosthwaite: > On Mon, Jul 2, 2012 at 8:52 PM, Kevin Wolf wrote: >> Am 02.07.2012 12:18, schrieb Peter Crosthwaite: >>> On Mon, Jul 2, 2012 at 8:01 PM, Kevin Wolf wrote: >>>> 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, >>> >>> Makes sense for small devices on embedded platforms. You end up with a >>> very simple and clean device model. The approach is totally broken for >>> HDDs but it does make some sense for the little embedded flashes where >>> you can get away with caching the entire device storage in RAM for the >>> lifetime of the system. >> >> It kind of works for read-only devices, it's just ugly there. With >> writeable devices it makes the VM unmigratable. >> > > Isnt it just a simple case of syncing the buffer with the backing > store on pre_save? Not if the buffer is only read during initialisation, which has long happened on the destination when pre_save runs. So you'd need to either migrate the whole block device content as suggested by PMM (works only for really small devices) or have a reopen in post_load. Both sounds rather hackish to me and likely doesn't work for block devices in general. Kevin