From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=49886 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OCBOA-0004nQ-LN
	for qemu-devel@nongnu.org; Wed, 12 May 2010 08:50:15 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <jamie@shareable.org>) id 1OCBO8-0008F5-UW
	for qemu-devel@nongnu.org; Wed, 12 May 2010 08:50:14 -0400
Received: from mail2.shareable.org ([80.68.89.115]:43588)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <jamie@shareable.org>) id 1OCBO8-0008Ew-P1
	for qemu-devel@nongnu.org; Wed, 12 May 2010 08:50:12 -0400
Date: Wed, 12 May 2010 13:50:08 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH 0/2] Enable qemu block layer to not flush
Message-ID: <20100512125008.GA19314@shareable.org>
References: <1273528310-7051-1-git-send-email-agraf@suse.de>
	<4BE881CB.3070303@codemonkey.ws>
	<C9620B81-D220-4E97-9949-E5E22E59AEBF@suse.de>
	<4BE884E0.5020703@codemonkey.ws>
	<20100511214832.GC30446@shareable.org>
	<AANLkTillXVFVdBLJnHDzreOEvNe264-QGdE_YBsSCwje@mail.gmail.com>
	<20100512094257.GA16879@shareable.org>
	<AANLkTilWoPMKyAqA4mlvHe6C-0z4_zocFU2-SKpSUp4u@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AANLkTilWoPMKyAqA4mlvHe6C-0z4_zocFU2-SKpSUp4u@mail.gmail.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: kwolf@redhat.com, g@shareable.org, qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>, hch@lst.de

Stefan Hajnoczi wrote:
> On Wed, May 12, 2010 at 10:42 AM, Jamie Lokier <jamie@shareable.org> wrote:
> > Stefan Hajnoczi wrote:
> >> Why add a nop AIO operation instead of setting
> >> BlockDriverState->enable_write_cache to zero?  In that case no write
> >> cache would be reported to the guest (just like cache=writethrough).
> >
> > Hmm.  If the guest sees write cache absent, that prevents changing the
> > cache policy on the host later (from not flushing to flushing), which
> > you might want to do after an OS install has finished and booted up.
> 
> Right.  There are 3 cases from the guest perspective:
> 
> 1. Disable write cache or no write cache.  Flushing not needed.
> 2. Disable flushing but leave write cache enabled.
> 3. Enable write cache and use flushing.
> 
> When we don't report a write cache at all, the guest is always stuck at 1.
> 
> If you're going to do this for installs and other temporary workloads,
> then enabling the write cache again isn't an issue.  After installing
> successfully, restart the guest with a sane cache= mode.

That only works if you're happy to reboot the guest after the process
finishes.  I guess that is usually fine, but it is a restriction.

Is it possible via QMP to request that the guest is paused when it
next reboots, so that QMP operations to change the cache= mode can be
done (as it's not safe to change the guest-visible disk write cache
availability when it's running, and probably a request to do so should
be denied).

-- Jamie