[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: Markus Armbruster
Subject: Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption
Date: Thu, 12 Jul 2012 15:42:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Kevin Wolf <address@hidden> writes:

> Am 02.07.2012 11:42, schrieb Peter Crosthwaite:
>> On Mon, Jul 2, 2012 at 7:04 PM, Kevin Wolf <address@hidden> 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.


reply via email to

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