Avi Kivity wrote:
> On 03/09/2010 01:00 AM, Jamie Lokier wrote:
> >Avi Kivity wrote:
> >
> >>I think we have to go with a qdev property as Christoph suggests. Then
> >>it becomes the management's responsibility to set it right.
> >>
> >How can the management be expected to know or follow d
On 03/09/2010 01:00 AM, Jamie Lokier wrote:
Avi Kivity wrote:
I think we have to go with a qdev property as Christoph suggests. Then
it becomes the management's responsibility to set it right.
How can the management be expected to know or follow dynamically
changing guest state? The
Avi Kivity wrote:
> I think we have to go with a qdev property as Christoph suggests. Then
> it becomes the management's responsibility to set it right.
How can the management be expected to know or follow dynamically
changing guest state? There guests which disable a drive's write
cache in som
Avi Kivity wrote:
> On 03/08/2010 12:29 PM, Juan Quintela wrote:
>> Avi Kivity wrote:
>> 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
On 03/08/2010 12:29 PM, Juan Quintela wrote:
Avi Kivity 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
Avi Kivity 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 bac
