From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sle7Y-0002Yw-7J for qemu-devel@nongnu.org; Mon, 02 Jul 2012 06:44:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sle7W-0005KH-A6 for qemu-devel@nongnu.org; Mon, 02 Jul 2012 06:44:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64138) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sle7W-0005Jr-1j for qemu-devel@nongnu.org; Mon, 02 Jul 2012 06:44:42 -0400 Message-ID: <4FF17B90.3090801@redhat.com> Date: Mon, 02 Jul 2012 12:44:32 +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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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 Maydell Cc: stefanha@linux.vnet.ibm.com, Stefan Hajnoczi , Markus Armbruster , qemu-devel@nongnu.org, Peter Crosthwaite , edgar.iglesias@gmail.com, john.williams@petalogix.com Am 02.07.2012 12:18, schrieb Peter Maydell: > On 2 July 2012 11:01, Kevin Wolf wrote: >> 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. > > It's much nicer to be able to produce an error message ("file > doesn't exist", "file is too short for this flash device") at > device startup rather than miles later on at first access, "file doesn't exist" is an error that occurs for the backend (-drive if=none), not for the -device, so you shouldn't have to deal with that at all. > and pulling in a 64K file at startup is a simple implementation. > 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. And this description doesn't even take things like cache coherency for image files into consideration. > I would have thought migration would be simpler with a "read > whole file at startup" implementation, because in that case > the required migration state is always "this block of memory", > rather than "sometimes this block of memory and sometimes a > flag which says we haven't initialised the memory and will > need to do a file read". Oh, so you're actually migrating the whole content of the flash device instead of using the same file on the migration destination? What's the advantage over rereading the file on the destination? You still need access to the file there, don't you? The approach with migrating the block device content probably works for your 64k flash, but what about my hard disk? Kevin