qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
	qemu-stable@nongnu.org, qemu-devel@nongnu.org,
	qemu-block@nongnu.org, mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 1/1] block-backend: allow flush on devices with open tray
Date: Wed, 7 Sep 2016 10:18:13 +0200	[thread overview]
Message-ID: <20160907081813.GB5113@noname.redhat.com> (raw)
In-Reply-To: <4f11e915-63c8-a42d-7cfc-498d8a694d1a@redhat.com>

Am 06.09.2016 um 23:44 hat John Snow geschrieben:
> On 09/05/2016 05:15 AM, Markus Armbruster wrote:
> >John Snow <jsnow@redhat.com> writes:
> >>(3) Just allow flushes to work on devices not visible to the guest,
> >>which is what I've done here. Internal requests should work, Guest
> >>requests should fail.
> >
> >I guess that's okay, ...
> >
> 
> Conceptually, QEMU should be allowed to flush things to its internal
> drive abstractions regardless of what it looks like to the guest
> whenever it decides it is necessary to.
> 
> In practice, I don't know how clean we are about separating out who
> is requesting the flush to know which to deny.

Maybe the move from bdrv_flush_all() to blk_flush_all() was wrong. If
you have a BDS that isn't currently attached to a guest device or at
least not accessible from the guest device's BB because of things like
an open tray, but the BDS has previously been written to, you still want
to flush it for migration.

The only other clean option I see is that we flush BDSes when they are
detached from the BB, or otherwise become unaccessible (e.g. the tray is
opened). And that second part suggests that it might be too easy to get
this one wrong, so maybe bdrv_flush_all() was the best option after all.

Kevin

      parent reply	other threads:[~2016-09-07  8:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-01 21:56 [Qemu-devel] [PATCH v2 0/1] block-backend: allow flush on devices with open tray John Snow
2016-09-01 21:56 ` [Qemu-devel] [PATCH v2 1/1] " John Snow
2016-09-01 22:11   ` Eric Blake
2016-09-01 22:17     ` John Snow
2016-09-01 23:48   ` [Qemu-devel] [Qemu-block] " Jeff Cody
2016-09-02  5:44   ` [Qemu-devel] " Markus Armbruster
2016-09-02 16:05     ` John Snow
2016-09-05  9:15       ` Markus Armbruster
2016-09-06 21:44         ` John Snow
2016-09-07  6:51           ` Markus Armbruster
2016-09-07  8:18           ` Kevin Wolf [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160907081813.GB5113@noname.redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).