Re: [Qemu-devel] [RFC][PATCH 0/2] Allow cache settings for block devices to be changed at runtime.

[Chunqiang Tang]

> Am 01.03.2011 10:55, schrieb Stefan Hajnoczi:
> > On Mon, Feb 28, 2011 at 3:48 PM, Kevin Wolf <address@hidden> wrote:
> >> Am 28.02.2011 16:35, schrieb Stefan Hajnoczi:
> >>> On Mon, Feb 28, 2011 at 3:12 PM, Kevin Wolf <address@hidden> 
wrote:
> >>>> Am 28.02.2011 12:49, schrieb Prerna Saxena:
> >>>>> The following patchset introduces monitor commands:
> >>>>>
> >>>>> 1. set_cache DEVICE CACHE-SETTING
> >>>>> Change cache settings for block device, DEVICE, through the 
monitor.
> >>>>> (Available options : 'none', 'writeback', 'writethrough')
> >>>>> Eg,
> >>>>> (qemu)set_cache ide0-hd0 none
> >>>>> -> Changes cache setting for ide0-hd0 to 'none'
> >>>>
> >>>> Not sure if adding this interface is a good idea. I see that you 
only
> >>>> add it for HMP, and we may consider that, but it's definitely not
> >>>> suitable for QMP.
> >>>>
> >>>> One reason is that none/writethrough/writeback/unsafe isn't really 
what
> >>>> we want to use long term. We want to separate advertising a write 
cache
> >>>> (which is guest visible) from things like whether to use O_DIRECT 
or not.
> >>>>
> >>>> In the past, Christoph mentioned that he had patches to make these
> >>>> separate and even let the guest change the "write cache enabled" 
flag,
> >>>> which would probably solve most of the use cases of this patch.
> >>>
> >>> Toggling host page cache at runtime is useful too because it saves
> >>> having to restart VMs.
> >>
> >> Not sure why I wanted to change that during runtime, but agreed,
> >> allowing to change parameters using the monitor is generally a good 
thing.
> >>
> >> However, I'm not sure if a command for changing the cache mode is the
> >> right solution, or if it should be something like a command to change
> >> block device options. (For example, what about toggling read-only or
> >> snapshot mode?)
> > 
> > Yes, I think you're right.  We should aim for a general interface
> > rather than having to add many more specific interfaces in the future.
> > 
> > CQ: Do you see a relation to the "update" interface you added to
> > adjust drive options at runtime for FVD?
> 
> On one hand it's a different set of options today. IIUC, qemu-img update
> refers to persistent per-image options like backing file, encryption,
> etc. This monitor command refers to temporary command line options like
> cache, snapshot mode etc.
> 
> On the other hand, we've had discussions before about storing a
> copy-on-read flag in images which makes sense as a command line option
> as well. The same may apply to things like the read-only flags.
> 
> So maybe these two sets of flags aren't that distinct from each other.
> 
> Kevin

Kevin is right. The 'qemu-img update' patch I posted recently is a general 
interface for manipulating persistent per-image options. Its 
implementation certainly differs from a one-time runtime monitor command. 

I can imagine two sets of flags: 1) those should only be updated in the 
persistent image (e.g., backing file) and its effect must be reflected at 
the time of opening an image, and 2) those flags that can be updated both 
in the persistent image and at runtime. For 2), the flag value 
persistently stored in the image is taken as the default value when an 
image is opened, and the flag value possibly can be further modified by a 
runtime monitor command. It seems that copy_on_read and prefetching fall 
in to category 2), with 'qemu-img update' handling persistent changes in 
image and Stefan H.'s monitor commands in QED handling runtime changes. If 
we want a general monitor interface for runtime flag changes, the 
interface may be similar to 'qemu-img update' but the implementation would 
be very different.

Specifically regarding the set_cache monitor command, it  allows 
flexibility, but probably will be rarely used. It also poses additional 
requires on the image format drivers, e.g., to flush metadata cache on the 
change of cache mode and to re-initialize internal data structure 
properly. 

Regards,
ChunQiang (CQ) Tang
Homepage: http://www.research.ibm.com/people/c/ctang