[Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Marc Bevand]

At boottime, the licensing mechanism in Windows examines the reply to
ATA/ATAPI IDENTIFY commands to determine if the hardware has been
upgraded and whether Windows needs to be "reactivated" or not.

I can confirm this because my Windows XP VM asked for reactivation
after a QEMU upgrade and I was able to remove the need for
reactivation by applying a patch similar to the one below (the
versions were all hardcoded to "0.9.0" -- the version of QEMU I was
running before).

To prevent this kind of problem from happening again, I suggest QEMU
stops returning its constantly changing version (QEMU_VERSION) in
replies to IDENTIFY commands. Instead a constant version string
such as "1.0" should be returned.

Comments ?

-marc


Index: hw/ide.c
===================================================================
--- hw/ide.c	(revision 5193)
+++ hw/ide.c	(working copy)
@@ -549,7 +549,7 @@
     put_le16(p + 20, 3); /* XXX: retired, remove ? */
     put_le16(p + 21, 512); /* cache size in sectors */
     put_le16(p + 22, 4); /* ecc bytes */
-    padstr((char *)(p + 23), QEMU_VERSION, 8); /* firmware version */
+    padstr((char *)(p + 23), "1.0", 8); /* firmware version */
     padstr((char *)(p + 27), "QEMU HARDDISK", 40); /* model */
 #if MAX_MULT_SECTORS > 1
     put_le16(p + 47, 0x8000 | MAX_MULT_SECTORS);
@@ -615,7 +615,7 @@
     put_le16(p + 20, 3); /* buffer type */
     put_le16(p + 21, 512); /* cache size in sectors */
     put_le16(p + 22, 4); /* ecc bytes */
-    padstr((char *)(p + 23), QEMU_VERSION, 8); /* firmware version */
+    padstr((char *)(p + 23), "1.0", 8); /* firmware version */
     padstr((char *)(p + 27), "QEMU DVD-ROM", 40); /* model */
     put_le16(p + 48, 1); /* dword I/O (XXX: should not be set on CDROM) */
 #ifdef USE_DMA_CDROM
@@ -669,7 +669,7 @@
     snprintf(buf, sizeof(buf), "QM%05d", s->drive_serial);
     padstr((char *)(p + 10), buf, 20);	/* Serial number in ASCII */
     put_le16(p + 22, 0x0004);			/* ECC bytes */
-    padstr((char *) (p + 23), QEMU_VERSION, 8);	/* Firmware Revision */
+    padstr((char *) (p + 23), "1.0", 8);	/* Firmware Revision */
     padstr((char *) (p + 27), "QEMU MICRODRIVE", 40);/* Model number */
 #if MAX_MULT_SECTORS > 1
     put_le16(p + 47, 0x8000 | MAX_MULT_SECTORS);
@@ -1821,7 +1821,7 @@
         buf[7] = 0; /* reserved */
         padstr8(buf + 8, 8, "QEMU");
         padstr8(buf + 16, 16, "QEMU DVD-ROM");
-        padstr8(buf + 32, 4, QEMU_VERSION);
+        padstr8(buf + 32, 4, "1.0");
         ide_atapi_cmd_reply(s, 36, max_len);
         break;
     case GPCMD_GET_CONFIGURATION:

Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Anthony Liguori]

Marc Bevand wrote:
> At boottime, the licensing mechanism in Windows examines the reply to
> ATA/ATAPI IDENTIFY commands to determine if the hardware has been
> upgraded and whether Windows needs to be "reactivated" or not.
>
> I can confirm this because my Windows XP VM asked for reactivation
> after a QEMU upgrade and I was able to remove the need for
> reactivation by applying a patch similar to the one below (the
> versions were all hardcoded to "0.9.0" -- the version of QEMU I was
> running before).
>
> To prevent this kind of problem from happening again, I suggest QEMU
> stops returning its constantly changing version (QEMU_VERSION) in
> replies to IDENTIFY commands. Instead a constant version string
> such as "1.0" should be returned.
>   

Wouldn't it be better to just use whatever QEMU_VERSION is right now 
with a big fat comment? At least then, any VM made with QEMU 0.9.1 won't 
require reactivation.

No point in breaking everyone by changing it to 1.0.

Regards,

Anthony Liguori

> Comments ?
>
> -marc
>
>
> Index: hw/ide.c
> ===================================================================
> --- hw/ide.c	(revision 5193)
> +++ hw/ide.c	(working copy)
> @@ -549,7 +549,7 @@
>      put_le16(p + 20, 3); /* XXX: retired, remove ? */
>      put_le16(p + 21, 512); /* cache size in sectors */
>      put_le16(p + 22, 4); /* ecc bytes */
> -    padstr((char *)(p + 23), QEMU_VERSION, 8); /* firmware version */
> +    padstr((char *)(p + 23), "1.0", 8); /* firmware version */
>      padstr((char *)(p + 27), "QEMU HARDDISK", 40); /* model */
>  #if MAX_MULT_SECTORS > 1
>      put_le16(p + 47, 0x8000 | MAX_MULT_SECTORS);
> @@ -615,7 +615,7 @@
>      put_le16(p + 20, 3); /* buffer type */
>      put_le16(p + 21, 512); /* cache size in sectors */
>      put_le16(p + 22, 4); /* ecc bytes */
> -    padstr((char *)(p + 23), QEMU_VERSION, 8); /* firmware version */
> +    padstr((char *)(p + 23), "1.0", 8); /* firmware version */
>      padstr((char *)(p + 27), "QEMU DVD-ROM", 40); /* model */
>      put_le16(p + 48, 1); /* dword I/O (XXX: should not be set on CDROM) */
>  #ifdef USE_DMA_CDROM
> @@ -669,7 +669,7 @@
>      snprintf(buf, sizeof(buf), "QM%05d", s->drive_serial);
>      padstr((char *)(p + 10), buf, 20);	/* Serial number in ASCII */
>      put_le16(p + 22, 0x0004);			/* ECC bytes */
> -    padstr((char *) (p + 23), QEMU_VERSION, 8);	/* Firmware Revision */
> +    padstr((char *) (p + 23), "1.0", 8);	/* Firmware Revision */
>      padstr((char *) (p + 27), "QEMU MICRODRIVE", 40);/* Model number */
>  #if MAX_MULT_SECTORS > 1
>      put_le16(p + 47, 0x8000 | MAX_MULT_SECTORS);
> @@ -1821,7 +1821,7 @@
>          buf[7] = 0; /* reserved */
>          padstr8(buf + 8, 8, "QEMU");
>          padstr8(buf + 16, 16, "QEMU DVD-ROM");
> -        padstr8(buf + 32, 4, QEMU_VERSION);
> +        padstr8(buf + 32, 4, "1.0");
>          ide_atapi_cmd_reply(s, 36, max_len);
>          break;
>      case GPCMD_GET_CONFIGURATION:
>
>
>   

Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Marc Bevand]

On Wed, Sep 10, 2008 at 5:30 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>
> Wouldn't it be better to just use whatever QEMU_VERSION is right now with a
> big fat comment? At least then, any VM made with QEMU 0.9.1 won't require
> reactivation.
> No point in breaking everyone by changing it to 1.0.

Yeah that could work too.

(However I don't expect that changing it to 1.0 would break everyone.
Only a minority. Because multiple hardware changes are necessary to
trigger a need for reactivacion. In my case, I was changing the MAC
address, upgrading to a 64-bit host (it made Windows see slightly
different CPUID results), and upgrading QEMU (it made Windows see new
hdd/dvd drive firmware versions). All 3 events were necessary to
trigger a need for reactivation.)

Ultimately however I think it should be user-configurable.

-- 
Marc Bevand

Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Glauber Costa]

On Wed, Sep 10, 2008 at 10:19 PM, Marc Bevand <m.bevand@gmail.com> wrote:
> On Wed, Sep 10, 2008 at 5:30 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>
>> Wouldn't it be better to just use whatever QEMU_VERSION is right now with a
>> big fat comment? At least then, any VM made with QEMU 0.9.1 won't require
>> reactivation.
>> No point in breaking everyone by changing it to 1.0.
>
> Yeah that could work too.
>
> (However I don't expect that changing it to 1.0 would break everyone.
> Only a minority. Because multiple hardware changes are necessary to
> trigger a need for reactivacion. In my case, I was changing the MAC
> address, upgrading to a 64-bit host (it made Windows see slightly
> different CPUID results), and upgrading QEMU (it made Windows see new
> hdd/dvd drive firmware versions). All 3 events were necessary to
> trigger a need for reactivation.)

given this info you just provided, this is probably a non-issue. After
all, if you're
changing so much things in your guest, you _are_ changing your machine in every
way that matters to the O.S. So if the O.S. is sucky enough to require
those kind of
activations, we should ultimately respect it.


-- 
Glauber Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Marc Bevand]

On Wed, Sep 10, 2008 at 6:40 PM, Glauber Costa <glommer@gmail.com> wrote:
>
> given this info you just provided, this is probably a non-issue. After
> all, if you're
> changing so much things in your guest, you _are_ changing your machine in every
> way that matters to the O.S. So if the O.S. is sucky enough to require
> those kind of activations, we should ultimately respect it.

Consider this scenario: I change the MAC and the host at some point;
no reactivation required. 10 months later I simply upgrade QEMU from
0.9.0 to 0.9.1 and change nothing else; reactivation is required. This
is not something an enduser would expect.

Another way to see it is that I was in control of the MAC and host
change, but not of the IDENTIFY replies. An enduser should always be
in control of the "hardware changes" he makes to a guest.

Also, I believe (but am not sure) that if I had installed Windows on
QEMU version A and upgraded to version B to C to D, then Windows would
require reactivation after the upgrade to D because it would be seen
as the 3rd "hardware change".

-- 
Marc Bevand

Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Jamie Lokier]

Marc Bevand wrote:
> Consider this scenario: I change the MAC and the host at some point;
> no reactivation required. 10 months later I simply upgrade QEMU from
> 0.9.0 to 0.9.1 and change nothing else; reactivation is required. This
> is not something an enduser would expect.

I agree.  (Also I agree with Glauber that the OS is sucky to care, but
it does and it's a notable use of QEMU to let you run Windows as a
guest so you can run Linux as a host :-)

> Another way to see it is that I was in control of the MAC and host
> change, but not of the IDENTIFY replies. An enduser should always be
> in control of the "hardware changes" he makes to a guest.

I agree.  If it's something which changes by default, then it should
be settable to a fixed value by the user somehow.  (Same goes for
other identifications the guest might see - I see that Microsoft
Virtual PC lets you specify a few of them in its config file.)

> Also, I believe (but am not sure) that if I had installed Windows on
> QEMU version A and upgraded to version B to C to D, then Windows would
> require reactivation after the upgrade to D because it would be seen
> as the 3rd "hardware change".

I don't think Windows counts these as multiple changes, but I'm not sure.

-- Jamie

Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Glauber Costa]

On Thu, Sep 11, 2008 at 5:18 AM, Jamie Lokier <jamie@shareable.org> wrote:
> Marc Bevand wrote:
>> Consider this scenario: I change the MAC and the host at some point;
>> no reactivation required. 10 months later I simply upgrade QEMU from
>> 0.9.0 to 0.9.1 and change nothing else; reactivation is required. This
>> is not something an enduser would expect.
>
> I agree.  (Also I agree with Glauber that the OS is sucky to care, but
> it does and it's a notable use of QEMU to let you run Windows as a
> guest so you can run Linux as a host :-)

My point is that in this case, you _are_ changing hardware. QEMU is a
piece of hardware anyway.
So yes, this is something the user would should expect. Maybe we don't
need to be so strict and don't
show the minor version in updates. But we can't guarantee that future
qemu updates won't change the
way the O.S. views hardware significantly.

>
>> Another way to see it is that I was in control of the MAC and host
>> change, but not of the IDENTIFY replies. An enduser should always be
>> in control of the "hardware changes" he makes to a guest.
>
> I agree.  If it's something which changes by default, then it should
> be settable to a fixed value by the user somehow.  (Same goes for
> other identifications the guest might see - I see that Microsoft
> Virtual PC lets you specify a few of them in its config file.)
>
>> Also, I believe (but am not sure) that if I had installed Windows on
>> QEMU version A and upgraded to version B to C to D, then Windows would
>> require reactivation after the upgrade to D because it would be seen
>> as the 3rd "hardware change".
>
> I don't think Windows counts these as multiple changes, but I'm not sure.
>
> -- Jamie
>
>
>



-- 
Glauber Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Jamie Lokier]

Glauber Costa wrote:
> On Thu, Sep 11, 2008 at 5:18 AM, Jamie Lokier <jamie@shareable.org> wrote:
> > Marc Bevand wrote:
> >> Consider this scenario: I change the MAC and the host at some point;
> >> no reactivation required. 10 months later I simply upgrade QEMU from
> >> 0.9.0 to 0.9.1 and change nothing else; reactivation is required. This
> >> is not something an enduser would expect.
> >
> > I agree.  (Also I agree with Glauber that the OS is sucky to care, but
> > it does and it's a notable use of QEMU to let you run Windows as a
> > guest so you can run Linux as a host :-)
> 
> My point is that in this case, you _are_ changing hardware. QEMU is a
> piece of hardware anyway.

If that is a hardware change, can we please have an option _not_ to
change the hardware when upgrading QEMU ;-)

> But we can't guarantee that future qemu updates won't change the way
> the O.S. views hardware significantly.

We should.  If upgrading QEMU changes the emulated hardware
significantly, it'll break some guests - not just Windows, but sane
guests with drivers not expecting the hardware to be suddenly different :-)

Significant changes should be accompanied by options, in the same way
that, say, you can select among different NICs, and ought to be able
to select among PIIX3 and PIIX4 etc.

Bug fixes and performance improvements are fine.

-- Jamie

Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Paul Brook]

> Bug fixes and performance improvements are fine.

The whole point of the drive firmware version is that it's supposed to change 
every time bug fixes and performance improvements are made.  I'm pretty sure 
it'll also change when you upgrade the firmware on a real drive.

As far as I'm concerned anything that relies on this value being constant over 
qemu is just plain broken.

Paul

Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Avi Kivity]

Paul Brook wrote:
> The whole point of the drive firmware version is that it's supposed to change 
> every time bug fixes and performance improvements are made.  I'm pretty sure 
> it'll also change when you upgrade the firmware on a real drive.
>
> As far as I'm concerned anything that relies on this value being constant over 
> qemu is just plain broken.
>   

Your users must love you.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Ian Kirk]

Paul Brook wrote:

> > Bug fixes and performance improvements are fine.
>
> The whole point of the drive firmware version is that it's supposed to
> change every time bug fixes and performance improvements are made.  I'm
> pretty sure it'll also change when you upgrade the firmware on a real
> drive.

How often do you upgrade the firmware on your (real) hard drives ?

For my 'hobby' equipment... never. In production, the only firmware
changes i've seen are in storage arrays, e.g. NetApp/EMC. I'm assuming the
change in the firmware of a SAN array doesn't really affect the host.

Re: [Qemu-devel] [PATCH] Don't use QEMU_VERSION in ATA/ATAPI replies to IDENTIFY cmds

[Paul Brook]

> How often do you upgrade the firmware on your (real) hard drives ?
>
> For my 'hobby' equipment... never. In production, the only firmware
> changes i've seen are in storage arrays, e.g. NetApp/EMC. I'm assuming the
> change in the firmware of a SAN array doesn't really affect the host.

I told that Intel recommend you upgrade the firmware on their recent 
mainstream SSD.

Paul