We arrange for the WIN_FLUSH_CACHE and WIN_FLUSH_CACHE_EXT
commands to use a new bdrv_aio_flush facility.
If there is an error, the ATA-7 spec says that we are supposed to know
which is the first block whose flush failed and leave that in the
block offset registers. However since we are using f(data)sync that's
not possible for us. There is sadly no way for us to report the error
which won't encourage the guest to try to understand what went wrong
and then do the flush again expecting the remaining blocks to be
written (as specified by ATA-7).
So if the asynchronous flush fails, we kill the disk by detaching
->bs. This makes it vanish: we don't generate any more interrupts,
leave status set to busy, and ignore future commands (and discard any
in-flight IO). Alan Cox reports that this will probably induce the
best available behaviour in guests (retry for a while and then give
up). Fine-grained error reporting is available if the guest turns off
the write cache.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Modified-by: Ian Jackson <ian.jackson@eu.citrix.com> Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>