[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption

From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption
Date: Mon, 2 Jul 2012 21:03:53 +1000

On Mon, Jul 2, 2012 at 8:59 PM, Peter Maydell <address@hidden> wrote:
> On 2 July 2012 11:44, Kevin Wolf <address@hidden> 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.


 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]