Kevin Wolf <kw...@redhat.com> writes: > Am 02.07.2012 11:42, schrieb Peter Crosthwaite: >> On Mon, Jul 2, 2012 at 7:04 PM, Kevin Wolf <kw...@redhat.com> wrote: >>> Am 02.07.2012 10:57, schrieb Peter Crosthwaite: >>>> No conditional on the qemu_coroutine_create. So it will always create >>>> a new coroutine for its work which will solve my problem. All I need >>>> to do is pump events once at the end of machine model creation. Any my >>>> coroutines will never yield or get queued by block/AIO. Sound like a >>>> solution? >>> >>> If you don't need the read data in your initialisation code, >> >> definately not :) Just as long as the read data is there by the time >> the machine goes live. Whats the current policy with bdrv_read()ing >> from init functions anyway? Several devices in qemu have init >> functions that read the entire storage into a buffer (then the guest >> just talks to the buffer rather than the backing store). > > 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.
I just stumbled over another problem case: encrypted images. Encrypted images specified on the command line get their keys from the monitor. -S is forced automatically. You can then use block_passwd to set keys. cont asks for keys still missing. However, device initialization happens *before* you get access to the monitor. Therefore, your init method runs without a key. It would be nice if the monitor was available before device initialization. Patches welcome. [...]
