On 11/23/2014 07:25 PM, Li, Liang Z wrote:
>>> # @auto-converge: If enabled, QEMU will automatically throttle down the
>>> guest
>>> # to speed up convergence of RAM migration. (since 1.6)
>>> #
>>> # Since: 1.2
>>> ##
>>> { 'enum': 'MigrationCapability',
>>> - 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks']
>>> }
>>> + 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
>>> + 'compress'] }
>>>
>
>> I'll repeat what I said on v1 (but this time, with some links to back it up
>> :)
>
>> We really need to avoid a proliferation of new commands, two per tunable
>> does not scale well. I think now is the time to implement my earlier
>> suggestion at making MigrationCapability become THE resource for > tunables:[please configure your mailer to wrap long lines] > >> https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg02274.html > > Hi, Eric > > I have read your proposal, and I just want to verify if I got it > exactly. Take the 'compresss-level' parameter for example, according to you > suggestion, should I implement a command 'set-migrate-capability > compress-level 1', or 'set-migrate-parameter compress-level 1' ? if it's > the former, how to keep the HMP back compatibility, as you know, the current > HMP framework will check the parameter type, the 'int' will be processed > differently from 'bool', ; if it's the latter, it seems like a ' > query-migrate-paramer ' command should be provided to keep consistency, not > query-migrate-capability. HMP back-compat is NOT a problem we need to worry about; it's okay to break the semantics if something else is easier to represent; it is only QMP where we have to remain backwards compatible. We already have set-migrate-capability, so that seems like the command to extend, instead of adding a new one. On the other hand, if it is easier for you to add a new HMP command that maps correctly to the underlying QMP command, then that is fine, too. The point of my proposal is that the QMP command can use a union to provide the correct typing as needed, without worrying about what HMP has to do to match that. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
