qemu-devel
[Top][All Lists]
Advanced

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

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption
Date: Mon, 02 Jul 2012 13:04:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

Am 02.07.2012 12:57, schrieb Peter Crosthwaite:
> On Mon, Jul 2, 2012 at 8:52 PM, Kevin Wolf <address@hidden> wrote:
>> Am 02.07.2012 12:18, schrieb Peter Crosthwaite:
>>> On Mon, Jul 2, 2012 at 8:01 PM, Kevin Wolf <address@hidden> wrote:
>>>> 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,
>>>
>>> Makes sense for small devices on embedded platforms. You end up with a
>>> very simple and clean device model. The approach is totally broken for
>>> HDDs but it does make some sense for the little embedded flashes where
>>> you can get away with caching the entire device storage in RAM for the
>>> lifetime of the system.
>>
>> It kind of works for read-only devices, it's just ugly there. With
>> writeable devices it makes the VM unmigratable.
>>
> 
> Isnt it just a simple case of syncing the buffer with the backing
> store on pre_save?

Not if the buffer is only read during initialisation, which has long
happened on the destination when pre_save runs. So you'd need to either
migrate the whole block device content as suggested by PMM (works only
for really small devices) or have a reopen in post_load. Both sounds
rather hackish to me and likely doesn't work for block devices in general.

Kevin



reply via email to

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