From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SleQA-00074H-OE for qemu-devel@nongnu.org; Mon, 02 Jul 2012 07:04:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SleQ8-000266-RR for qemu-devel@nongnu.org; Mon, 02 Jul 2012 07:03:58 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:59038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SleQ8-00025y-KR for qemu-devel@nongnu.org; Mon, 02 Jul 2012 07:03:56 -0400 Received: by bkty12 with SMTP id y12so784105bkt.4 for ; Mon, 02 Jul 2012 04:03:54 -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> <4FF17B90.3090801@redhat.com> Date: Mon, 2 Jul 2012 21:03:53 +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: Peter Maydell Cc: Kevin Wolf , stefanha@linux.vnet.ibm.com, Stefan Hajnoczi , Markus Armbruster , qemu-devel@nongnu.org, edgar.iglesias@gmail.com, john.williams@petalogix.com On Mon, Jul 2, 2012 at 8:59 PM, Peter Maydell wrote: > On 2 July 2012 11:44, Kevin Wolf wrote: >> Am 02.07.2012 12:18, schrieb Peter Maydell: >>> Why complicate things by adding code for "if this is the first >>> access then read in the file"? >> >> Because then it works. :-) >> >> Migration works more or less like this: >> >> 1. Destination creates device model based on command line >> 2. RAM is copied live, source keeps running >> 3. Source stops, device state is transferred >> 4. Destination starts running the VM >> >> Reading from a block device is meaningful the earliest in step 3, >> because at earlier points the guest still runs on the source and can >> overwrite the data on the block device. If you're reading in the whole >> image, you're doing it in step 1, so your data will be outdated by the >> time the migration completes. > > For pflash_cfi01 migration will work because although we read > the file (slightly pointlessly) in step 1, we will get the correct > contents transferred over in step 2, because we call vmstate_register_ram() > in device init. > > We need to migrate flash contents like that anyway, to handle the > case of "no backing file, Yeah these little flashes also tend to support a mode where there is no backing (bdrv) file at all. If all your doing is testing smoke testing a driver then you can boot with no -drive args and the device model knows to just implement the buffer and init it to something sensible. If there needs to be a device-size buffer to support this behaviour in non-bdrv mode then in might as well be there for bdrv mode as well. Regards, Peter flash starts empty and gets whatever the > guest writes to it for as long as the guest is alive". > >> The approach with migrating the block device content probably works for >> your 64k flash, but what about my hard disk? > > I'm not claiming this is a good approach for everything, just for > some things. > > -- PMM