On 16/09/2016 02:09, John Snow wrote: > > > On 09/15/2016 08:06 PM, Paolo Bonzini wrote: >> >> >> On 16/09/2016 01:42, John Snow wrote: >>> One more try. >>> >>> The move to blk_flush altered the behavior of migration and flushing >>> nodes that are not reachable via the guest, but are still reachable >>> via QEMU and may or may not need to be flushed. >>> >>> This is likely the simplest solution for now until we nail down our >>> policy a bit more. >>> >>> This is intended for 2.6.2 and/or 2.7.1, to fix problems with libvirt >>> et al being unable to migrate QEMU when the CDROM tray is open. >>> >>> v3: >>> Trying to take a hint from Kevin, reinstating bdrv_flush_all. >>> If it's not what we want, we can try moving back to v2, >>> acknowledging that a nicer solution in the future: >>> (A) Can skip flushing on devices that just don't need it, and >>> (B) Optionally institutes some sort of flush-on-eject policy. >> >> If you move flushing from platform_fixed_ioport_writew's blk_flush_all >> to blk_flush calls in pci_piix3_xen_ide_unplug, you can get rid of >> blk_flush_all completely. > > I assume you mean in addition to re-adding bdrv_flush_all for the sake > of vm_stop, we can also get rid of blk_flush_all from xen and avoid the > duplication?
Yep. Devices really should not use the *_all() variants. Paolo