Re: [Qemu-devel] [V2 2/2]Qemu: Add commands "hostcache_set" and "hostcache_get"

[Stefan Hajnoczi]

On Mon, May 23, 2011 at 1:58 PM, Kevin Wolf <address@hidden> wrote:
> Am 23.05.2011 12:00, schrieb Stefan Hajnoczi:
>> On Mon, May 23, 2011 at 8:04 AM, Supriya Kannery <address@hidden> wrote:
>>> On 05/20/2011 01:50 PM, Stefan Hajnoczi wrote:
>>>>
>>>> On Thu, May 19, 2011 at 10:38:03PM +0530, Supriya Kannery wrote:
>>>>>
>>>>> Monitor commands "hostcache_set" and "hostcache_get" added for dynamic
>>>>> host cache change and display of host cache setting respectively.
>>>>
>>>> A generic command for changing block device options would be nice,
>>>> althought I don't see other options where it makes sense to change them
>>>> at runtime.
>>>>
>>>> The alternative would be:
>>>>
>>>> block_set hostcache on
>>>>
>>>> "block_set", {"device": "ide1-cd0", "name": "hostcache", "enable": true}
>>>>
>>>> The hostcache_get information would be part of query-block output:
>>>>          {
>>>>             "device":"ide0-hd0",
>>>>             "locked":false,
>>>>             "removable":false,
>>>>             "inserted":{
>>>>                "ro":false,
>>>>                "drv":"qcow2",
>>>>                "encrypted":false,
>>>>                "file":"disks/test.img"
>>>>               "hostcache":true,
>>>>             },
>>>>             "type":"hd"
>>>>          },
>>>>
>>>> This approach is extensible if more options need to be exposed.
>>>
>>> Sure, I will resubmit this patchset, after making this feature more generic.
>>> Can you pls help finding atleast one or two options (other than hostcache)
>>> which can be changed dynamically. This will help me evaluate the generic
>>> approach.
>>
>> Hang on, let's see if we can get agreement from Kevin and others
>> before taking this approach.  Like I said, I don't see other options
>> that should be changed at runtime.
>
> Things like enabling copy on read could fit here.
>
> Generally I'm in favour of having a generic command. We just need to pay
> attention not to include things that we don't want to maintain long
> term, i.e. just putting the current cache=... parameter into the
> argument isn't going to work. Maybe two booleans 'o_direct' and
> 'ignore_flushes' is what we want to have. The same structure should be
> used for blkdev_add then, even though it will allow some more options.

Supriya, it sounds to me like the generic block_set command and
query-block integration is an acceptable approach.

Stefan