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

[Kevin Wolf <kwolf@redhat.com>]

Am 02.07.2012 12:18, schrieb Peter Maydell:
> On 2 July 2012 11:01, Kevin Wolf <kwolf@redhat.com> 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