[Spice-devel] [PATCH 1/1] Add API to turn on backwards compatibility mode

Gerd Hoffmann kraxel at redhat.com
Fri Aug 27 06:08:43 PDT 2010


>> As you are talking about "set of features" already ...
>>
>> I think we should use a feature bitmask instead of a version number in
>> the API.
>
> How would you use this in qemu though? Say you link to spice 0.10.0,
> which has a set of new features not in 0.8.0. Why would you want to make
> a spice instance that doesn't use all features in 0.10.0, yet is not
> compatible with 0.8.0, so you can't migrate between them.

I would only enable features qemu knows about, i.e. something like

         features  = spice_get_features()
         features &= qemu_supported_features;
         spice_server_enable_features(features);

Where qemu_supported_features is the set of features the qemu qxl code 
knows about and can handle.  Have options to turn off specific features.

In case a new release adds multiple new features users / admins might 
want to selectively enable/disable them depending on how they affect 
compatibility.  qemu live migration compatibility is only affected in 
case the new feature requires additional state to be saved.  client 
compatibility is only affected in case the wire protocol changes.  So it 
might make sense to enable a subset of the new features, although that 
most likely isn't the common case.

> Right now we don't do any compat with 0.4, but the plan is that
> eventually we want to add a qemu mode where it doesn't use offscreen
> surfaces, nor the new qxl pci device, and allows migration to/from spice
> 0.4.0 instances.

It's there.  The new qxl device handles old guest drivers just fine. 
With the spice.v17 branch even live migration should work.  At least new 
qxl parses old qxl state just fine when switched into compatibility 
mode.  Not fully tested yet though due to some non-spice-related 
migration issues.

cheers,
   Gerd



More information about the Spice-devel mailing list