qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 0/2] block: allow flush on devices with open


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v4 0/2] block: allow flush on devices with open tray
Date: Tue, 20 Sep 2016 14:16:07 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 19.09.2016 um 22:58 hat Max Reitz geschrieben:
> On 19.09.2016 18:44, John Snow wrote:
> > Final re-send for wording.
> > 
> > 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.
> > 
> > v4:
> >  Commit message update.
> > 
> > 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.
> > 
> > ________________________________________________________________________________
> > 
> > For convenience, this branch is available at:
> > https://github.com/jnsnow/qemu.git branch atapi-tray-migfix
> > https://github.com/jnsnow/qemu/tree/atapi-tray-migfix
> > 
> > This version is tagged atapi-tray-migfix-v4:
> > https://github.com/jnsnow/qemu/releases/tag/atapi-tray-migfix-v4
> > 
> > John Snow (2):
> >   block: reintroduce bdrv_flush_all
> >   qemu: use bdrv_flush_all for vm_stop et al
> > 
> >  block/io.c            | 25 +++++++++++++++++++++++++
> >  cpus.c                |  4 ++--
> >  include/block/block.h |  1 +
> >  3 files changed, 28 insertions(+), 2 deletions(-)
> 
> Reviewed-by: Max Reitz <address@hidden>

Begs the question: Who is supposed to merge this? Stefan/Fam, who are
formally responsible for block/io.c? Or one of us because it's more
about managing block devices?

Kevin

Attachment: pgpqU2Mjhpi8t.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]