On Mon, Jul 2, 2012 at 8:59 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 2 July 2012 11:44, Kevin Wolf <kw...@redhat.com> 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
