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

[Avi Kivity]

On 03/08/2010 12:29 PM, Juan Quintela wrote:
> Avi Kivity<address@hidden>  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