On Mon, Mar 08, 2010 at 09:47:32AM +0000, Jamie Lokier wrote: > Assuming the outcome is that it becomes a qdev property, and stays > preserved across migrations, even if the backing device access > changes, then I think the right thing is to dynamically decide to set > O_DSYNC and/or call fdatasync before completing writes from qemu when > the guest thinks enable_write_cache=0 (or sets it to 0). With > cache=none, that would set O_DSYNC|O_DIRECT if the two flags do work > properly together on our favourite hosts. > > Thus enable_write_cache won't always have the default value for the > different backing device access type, but it will match the guest's > expectations and be actually safe. Moreover more, by responding to > the guest changing that, it's closer to behaving like real harware.
I'd have to look at other uses of qdev, but I would assume that we always look at the qdev properties and only use the existing drive suboptions as compatiblity if we do not have the qdev properties set.
