[Qemu-devel] cross version compatibility and qemu version

[Qemu-devel] cross version compatibility and qemu version

[Michael S. Tsirkin]

I was looking at cross-version migration issues, in the
hope that we can fix most of them for release 1.6.
I noticed that we still use QEMU_VERSION in hardware.

hw/scsi/megasas.c:    snprintf(info.package_version, 0x60, "%s-QEMU", QEMU_VERSION);
hw/usb/redirect.c:#define VERSION "qemu usb-redir guest " QEMU_VERSION

These look like a bug that will break cross version
compatibility - I think need to change both instances
to qemu_get_version()?

megasas also includes the build date/time of QEMU - this
clearly removed any hope to be exactly compatible.
I'm not sure what to do with respect to this:
let's stop the clock at an arbitrary date?
Add property for management to control this as well?

We also probably want to fix this in -stable versions.

Re: [Qemu-devel] cross version compatibility and qemu version

[Peter Maydell]

On 4 August 2013 11:20, Michael S. Tsirkin <mst@redhat.com> wrote:
> I was looking at cross-version migration issues, in the
> hope that we can fix most of them for release 1.6.
> I noticed that we still use QEMU_VERSION in hardware.

We fixed most of these back in 2012, but I guess one or
two slipped through the net.

> hw/scsi/megasas.c:    snprintf(info.package_version, 0x60, "%s-QEMU", QEMU_VERSION);
> hw/usb/redirect.c:#define VERSION "qemu usb-redir guest " QEMU_VERSION
>
> These look like a bug that will break cross version
> compatibility - I think need to change both instances
> to qemu_get_version()?

The USB one is OK, as the version string is only passed
to the usbredir-host for debugging purposes and isn't
visible to the guest. See this patch which reverted a
change which made it use qemu_get_version():

http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg01903.html

> megasas also includes the build date/time of QEMU - this
> clearly removed any hope to be exactly compatible.
> I'm not sure what to do with respect to this:
> let's stop the clock at an arbitrary date?
> Add property for management to control this as well?

I would go for using an arbitrary (and preferably
obviously wrong) date, or just dropping the fields
altogether if the hardware format permits (it probably
doesn't).

-- PMM

Re: [Qemu-devel] cross version compatibility and qemu version

[Andreas Färber]

Am 04.08.2013 12:25, schrieb Peter Maydell:
> On 4 August 2013 11:20, Michael S. Tsirkin <mst@redhat.com> wrote:
>> I was looking at cross-version migration issues, in the
>> hope that we can fix most of them for release 1.6.
>> I noticed that we still use QEMU_VERSION in hardware.
> 
> We fixed most of these back in 2012, but I guess one or
> two slipped through the net.
> 
>> hw/scsi/megasas.c:    snprintf(info.package_version, 0x60, "%s-QEMU", QEMU_VERSION);
>> hw/usb/redirect.c:#define VERSION "qemu usb-redir guest " QEMU_VERSION
>>
>> These look like a bug that will break cross version
>> compatibility - I think need to change both instances
>> to qemu_get_version()?
[...]
>> megasas also includes the build date/time of QEMU - this
>> clearly removed any hope to be exactly compatible.
>> I'm not sure what to do with respect to this:
>> let's stop the clock at an arbitrary date?
>> Add property for management to control this as well?
> 
> I would go for using an arbitrary (and preferably
> obviously wrong) date, or just dropping the fields
> altogether if the hardware format permits (it probably
> doesn't).

Let's simply CC Hannes and ask him. :)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg