[Qemu-devel] Re: bs->enable_write_cache and the guest ABI

[Avi Kivity <avi@redhat.com>]

On 03/08/2010 12:29 PM, Juan Quintela wrote:
> Avi Kivity<avi@redhat.com>  wrote:
>    
>> block.c says:
>>
>>      
>>>      /*
>>>       * Yes, BDRV_O_NOCACHE aka O_DIRECT means we have to present a
>>>       * write cache to the guest.  We do need the fdatasync to flush
>>>       * out transactions for block allocations, and we maybe have a
>>>       * volatile write cache in our backing device to deal with.
>>>       */
>>>      if (flags&  (BDRV_O_CACHE_WB|BDRV_O_NOCACHE))
>>>          bs->enable_write_cache = 1;
>>>        
>> This means that if I start a guest with cache=writethrough and then
>> restart (or live migrate) it with cache=none, then the guest will see
>> a change, even though the user only changed the drive's backing, not
>> something guest visible.  In the case of live migration, the guest
>> will not even notice the change and we may be at risk of data loss.
>>
>> For 0.13 I propose setting enable_write_cache to true unconditionally.
>> For 0.12 the question is more difficult, since we'll be changing the
>> guest ABI.  Given that guests are unlikely not to be able to cope with
>> write caches, and that the alternative is data loss, I believe that's
>> also the right solution there.
>>      
> For RHEL I setted with adding enable_write_cache to the migration
> state.  As you state, that value is guest visible.  I can update that
> patches to qemu.  When I migrated from an old version, I just set that
> value to 0.
>
> What do you think?
>    

I think we have to go with a qdev property as Christoph suggests.  Then 
it becomes the management's responsibility to set it right.

-- 
error compiling committee.c: too many arguments to function