[Qemu-devel] [PATCH 0/2] Virtual Machine Generation ID

[Qemu-devel] [PATCH 0/2] Virtual Machine Generation ID

[Gal Hammer]

Hi,

A two parts patch to add a QEmu support for Microsoft's Virtual Machine
Generation ID device.

The first one add a new ACPI directive which allow to use a 16-bytes
buffer in an ACPI table. This buffer is for storing the VM's UUID.

The second is the ACPI tables changes and the required command line
parameter.

Your comment are welcomed.

Thanks,

    Gal.

Gal Hammer (2):
  i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive.
  i386: Add a Virtual Machine Generation ID device.

 hw/i386/acpi-build.c    | 23 +++++++++++++++++++++++
 hw/i386/ssdt-misc.dsl   | 33 +++++++++++++++++++++++++++++++++
 qemu-options.hx         |  9 +++++++++
 scripts/acpi_extract.py | 23 ++++++++++++++---------
 vl.c                    | 11 +++++++++++
 5 files changed, 90 insertions(+), 9 deletions(-)

-- 
1.9.3

[Qemu-devel] [PATCH 1/2] i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive.

[Gal Hammer]

Add a 16-bytes buffer to allow storing a 128-bit UUID value in an
ACPI table.

Signed-off-by: Gal Hammer <ghammer@redhat.com>
---
 scripts/acpi_extract.py | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/scripts/acpi_extract.py b/scripts/acpi_extract.py
index 22ea468..88314fc 100755
--- a/scripts/acpi_extract.py
+++ b/scripts/acpi_extract.py
@@ -139,13 +139,16 @@ def aml_name_string(offset):
         offset += 1
     return offset;
 
-# Given data offset, find 8 byte buffer offset
-def aml_data_buffer8(offset):
-    #0x08 NameOp NameString DataRef
-    expect = [0x11, 0x0B, 0x0A, 0x08]
+# Given data offset, find variable length byte buffer offset
+def aml_data_buffer(offset, length):
+    #0x11 PkgLength BufferSize ByteList
+    if (length > 63):
+        die( "Name offset 0x%x: expected an one byte PkgLength (length<=63)" %
+             (offset));
+    expect = [0x11, length+3, 0x0A, length]
     if (aml[offset:offset+4] != expect):
         die( "Name offset 0x%x: expected %s actual %s" %
-             (offset, aml[offset:offset+4], expect))
+             (offset, expect, aml[offset:offset+4]))
     return offset + len(expect)
 
 # Given data offset, find dword const offset
@@ -172,9 +175,9 @@ def aml_data_byte_const(offset):
              (offset, aml[offset]));
     return offset + 1;
 
-# Find name'd buffer8
-def aml_name_buffer8(offset):
-    return aml_data_buffer8(aml_name_string(offset) + 4)
+# Find name'd buffer
+def aml_name_buffer(offset, length):
+    return aml_data_buffer(aml_name_string(offset) + 4, length)
 
 # Given name offset, find dword const offset
 def aml_name_dword_const(offset):
@@ -308,7 +311,9 @@ for i in range(len(asl)):
         output[array] = aml
         continue
     if (directive == "ACPI_EXTRACT_NAME_BUFFER8"):
-        offset = aml_name_buffer8(offset)
+        offset = aml_name_buffer(offset, 8)
+    elif (directive == "ACPI_EXTRACT_NAME_BUFFER16"):
+        offset = aml_name_buffer(offset, 16)
     elif (directive == "ACPI_EXTRACT_NAME_DWORD_CONST"):
         offset = aml_name_dword_const(offset)
     elif (directive == "ACPI_EXTRACT_NAME_WORD_CONST"):
-- 
1.9.3

[Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.

[Gal Hammer]

Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table.

The GUID is set using a new "-vmgenid" command line parameter.

Signed-off-by: Gal Hammer <ghammer@redhat.com>
---
 hw/i386/acpi-build.c  | 23 +++++++++++++++++++++++
 hw/i386/ssdt-misc.dsl | 33 +++++++++++++++++++++++++++++++++
 qemu-options.hx       |  9 +++++++++
 vl.c                  | 11 +++++++++++
 4 files changed, 76 insertions(+)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 816c6d9..838c72c 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -54,6 +54,9 @@
 #include "qapi/qmp/qint.h"
 #include "qom/qom-qobject.h"
 
+extern uint8_t vm_generation_id[16];
+extern bool vm_generation_id_set;
+
 /* These are used to size the ACPI tables for -M pc-i440fx-1.7 and
  * -M pc-i440fx-2.0.  Even if the actual amount of AML generated grows
  * a little bit, there should be plenty of free space since the DSDT
@@ -1051,6 +1054,7 @@ build_ssdt(GArray *table_data, GArray *linker,
     unsigned acpi_cpus = guest_info->apic_id_limit;
     int ssdt_start = table_data->len;
     uint8_t *ssdt_ptr;
+    uint32_t vm_gid_physical_address;
     int i;
 
     /* The current AML generator can cover the APIC ID range [0..255],
@@ -1076,6 +1080,25 @@ build_ssdt(GArray *table_data, GArray *linker,
     ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
                       ssdt_isa_pest[0], 16, misc->pvpanic_port);
 
+    if (vm_generation_id_set) {
+        uint8_t *vm_gid_ptr;
+
+        vm_gid_physical_address = ssdt_start +  ssdt_acpi_vm_gid[0];
+        vm_gid_ptr = acpi_data_get_ptr(ssdt_ptr, sizeof(ssdp_misc_aml),
+                                       ssdt_acpi_vm_gid[0], 16);
+        memcpy(vm_gid_ptr, vm_generation_id, sizeof(vm_generation_id));
+
+        bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
+                                       ACPI_BUILD_TABLE_FILE,
+                                       table_data, ssdt_ptr + ssdt_acpi_vm_gid_addr[0],
+                                       sizeof(uint32_t));
+    } else {
+        vm_gid_physical_address = 0;
+    }
+
+    ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
+                      ssdt_acpi_vm_gid_addr[0], 32, vm_gid_physical_address);
+
     ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
                       ssdt_mctrl_nr_slots[0], 32, nr_mem);
 
diff --git a/hw/i386/ssdt-misc.dsl b/hw/i386/ssdt-misc.dsl
index d329b8b..8a001a7 100644
--- a/hw/i386/ssdt-misc.dsl
+++ b/hw/i386/ssdt-misc.dsl
@@ -118,6 +118,39 @@ DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
         }
     }
 
+    Scope(\_SB) {
+
+        Device(VMGI) {
+            Name(_HID, "QEMU0002")
+            Name(_CID, "VM_Gen_Counter")
+            Name(_DDN, "VM_Gen_Counter")
+
+            ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr
+            Name(VGIA, 0x12345678)
+
+            ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid
+            Name(VGID, Buffer(16) {
+                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 })
+
+            Method(_STA, 0, NotSerialized) {
+                Store(VGIA, Local0)
+                If (LEqual(Local0, Zero)) {
+                    Return (0x00)
+                } Else {
+                    Return (0x0F)
+                }
+            }
+
+            Method(ADDR, 0, Serialized) {
+                Store(Package(2) { }, Local0)
+                Store(VGIA, Index(Local0, 0))
+                Store(0x0000, Index(Local0, 1))
+                return (Local0)
+            }
+        }
+    }
+
     External(MEMORY_SLOT_NOTIFY_METHOD, MethodObj)
     Scope(\_SB.PCI0) {
         Device(MEMORY_HOPTLUG_DEVICE) {
diff --git a/qemu-options.hx b/qemu-options.hx
index 96516c1..a6d475c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -369,6 +369,15 @@ STEXI
 Set system UUID.
 ETEXI
 
+DEF("vmgenid", HAS_ARG, QEMU_OPTION_vmgenid,
+    "-vmgenid %08x-%04x-%04x-%04x-%012x\n"
+    "                specify the virtual machine generation ID\n", QEMU_ARCH_I386)
+STEXI
+@item -uuid @var{uuid}
+@findex -uuid
+Set the virtual machine generation ID.
+ETEXI
+
 STEXI
 @end table
 ETEXI
diff --git a/vl.c b/vl.c
index a8029d5..a5ef0d5 100644
--- a/vl.c
+++ b/vl.c
@@ -203,6 +203,9 @@ NodeInfo numa_info[MAX_NODES];
 uint8_t qemu_uuid[16];
 bool qemu_uuid_set;
 
+uint8_t vm_generation_id[16];
+bool vm_generation_id_set;
+
 static QEMUBootSetHandler *boot_set_handler;
 static void *boot_set_opaque;
 
@@ -3784,6 +3787,14 @@ int main(int argc, char **argv, char **envp)
                 }
                 qemu_uuid_set = true;
                 break;
+	    case QEMU_OPTION_vmgenid:
+	        if(qemu_uuid_parse(optarg, vm_generation_id) < 0) {
+	            fprintf(stderr, "Fail to parse UUID string."
+	                    " Wrong format.\n");
+	            exit(1);
+	        }
+	        vm_generation_id_set = true;
+	        break;
 	    case QEMU_OPTION_option_rom:
 		if (nb_option_roms >= MAX_OPTION_ROMS) {
 		    fprintf(stderr, "Too many option ROMs\n");
-- 
1.9.3

Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.

[Paolo Bonzini]

Il 10/08/2014 13:32, Gal Hammer ha scritto:
> Based on Microsoft's sepecifications (paper can be dowloaded from
> http://go.microsoft.com/fwlink/?LinkId=260709), add a device
> description to the SSDT ACPI table.
> 
> The GUID is set using a new "-vmgenid" command line parameter.
> 
> Signed-off-by: Gal Hammer <ghammer@redhat.com>
> ---
>  hw/i386/acpi-build.c  | 23 +++++++++++++++++++++++
>  hw/i386/ssdt-misc.dsl | 33 +++++++++++++++++++++++++++++++++
>  qemu-options.hx       |  9 +++++++++
>  vl.c                  | 11 +++++++++++
>  4 files changed, 76 insertions(+)

Please make this a new device (like pvpanic), instead of adding a new
command-line option.

> 
> +    Scope(\_SB) {
> +
> +        Device(VMGI) {
> +            Name(_HID, "QEMU0002")
> +            Name(_CID, "VM_Gen_Counter")
> +            Name(_DDN, "VM_Gen_Counter")
> +
> +            ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr
> +            Name(VGIA, 0x12345678)
> +
> +            ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid
> +            Name(VGID, Buffer(16) {
> +                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 })
> +
> +            Method(_STA, 0, NotSerialized) {
> +                Store(VGIA, Local0)
> +                If (LEqual(Local0, Zero)) {
> +                    Return (0x00)
> +                } Else {
> +                    Return (0x0F)
> +                }
> +            }
> +
> +            Method(ADDR, 0, Serialized) {
> +                Store(Package(2) { }, Local0)
> +                Store(VGIA, Index(Local0, 0))
> +                Store(0x0000, Index(Local0, 1))
> +                return (Local0)
> +            }
> +        }
> +    }
> +

Please either put this in the DSDT, or omit the Device altogether if you
put it in the SSDT and there is no VMGID device.

Thanks,

Paolo

Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.

[Gal Hammer]

Hi,

On 10/08/2014 20:22, Paolo Bonzini wrote:

> Il 10/08/2014 13:32, Gal Hammer ha scritto:
>> Based on Microsoft's sepecifications (paper can be dowloaded from
>> http://go.microsoft.com/fwlink/?LinkId=260709), add a device
>> description to the SSDT ACPI table.
>>
>> The GUID is set using a new "-vmgenid" command line parameter.
>>
>> Signed-off-by: Gal Hammer <ghammer@redhat.com>
>> ---
>>   hw/i386/acpi-build.c  | 23 +++++++++++++++++++++++
>>   hw/i386/ssdt-misc.dsl | 33 +++++++++++++++++++++++++++++++++
>>   qemu-options.hx       |  9 +++++++++
>>   vl.c                  | 11 +++++++++++
>>   4 files changed, 76 insertions(+)
>
> Please make this a new device (like pvpanic), instead of adding a new
> command-line option.

There is a problem with this request. I don't want to use ISA because it 
is obsolete, PCI is overkill for such a device and a SYSBUS (like HPET) 
device doesn't effect the command line options.

Did I miss something in SYSBUS and that's was the reason it didn't 
appear in the "-device ?" list?

>>
>> +    Scope(\_SB) {
>> +
>> +        Device(VMGI) {
>> +            Name(_HID, "QEMU0002")
>> +            Name(_CID, "VM_Gen_Counter")
>> +            Name(_DDN, "VM_Gen_Counter")
>> +
>> +            ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr
>> +            Name(VGIA, 0x12345678)
>> +
>> +            ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid
>> +            Name(VGID, Buffer(16) {
>> +                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>> +                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 })
>> +
>> +            Method(_STA, 0, NotSerialized) {
>> +                Store(VGIA, Local0)
>> +                If (LEqual(Local0, Zero)) {
>> +                    Return (0x00)
>> +                } Else {
>> +                    Return (0x0F)
>> +                }
>> +            }
>> +
>> +            Method(ADDR, 0, Serialized) {
>> +                Store(Package(2) { }, Local0)
>> +                Store(VGIA, Index(Local0, 0))
>> +                Store(0x0000, Index(Local0, 1))
>> +                return (Local0)
>> +            }
>> +        }
>> +    }
>> +
>
> Please either put this in the DSDT, or omit the Device altogether if you
> put it in the SSDT and there is no VMGID device.

I'm not sure I understand this comment. I've put the new device in the 
SSDT table (like pvpanic) and add a _STA method which disable the device 
if no GUID's address is set (VGIA). The device doesn't show in the 
Device Manager if it was not added using the command line.

     Gal.

> Thanks,
>
> Paolo
>

Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.

[Paolo Bonzini]

Il 12/08/2014 10:02, Gal Hammer ha scritto:
> Hi,
> 
> On 10/08/2014 20:22, Paolo Bonzini wrote:
> 
>> Il 10/08/2014 13:32, Gal Hammer ha scritto:
>>> Based on Microsoft's sepecifications (paper can be dowloaded from
>>> http://go.microsoft.com/fwlink/?LinkId=260709), add a device
>>> description to the SSDT ACPI table.
>>>
>>> The GUID is set using a new "-vmgenid" command line parameter.
>>>
>>> Signed-off-by: Gal Hammer <ghammer@redhat.com>
>>> ---
>>>   hw/i386/acpi-build.c  | 23 +++++++++++++++++++++++
>>>   hw/i386/ssdt-misc.dsl | 33 +++++++++++++++++++++++++++++++++
>>>   qemu-options.hx       |  9 +++++++++
>>>   vl.c                  | 11 +++++++++++
>>>   4 files changed, 76 insertions(+)
>>
>> Please make this a new device (like pvpanic), instead of adding a new
>> command-line option.
> 
> There is a problem with this request. I don't want to use ISA because it
> is obsolete, PCI is overkill for such a device and a SYSBUS (like HPET)
> device doesn't effect the command line options.
> 
> Did I miss something in SYSBUS and that's was the reason it didn't
> appear in the "-device ?" list?

For a sysbus device, you can override the
cannot_instantiate_with_device_add_yet field of DeviceClass in your
class_init function.

>>>
>>> +    Scope(\_SB) {
>>> +
>>> +        Device(VMGI) {
>>> +            Name(_HID, "QEMU0002")
>>> +            Name(_CID, "VM_Gen_Counter")
>>> +            Name(_DDN, "VM_Gen_Counter")
>>> +
>>> +            ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr
>>> +            Name(VGIA, 0x12345678)
>>> +
>>> +            ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid
>>> +            Name(VGID, Buffer(16) {
>>> +                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>>> +                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 })
>>> +
>>> +            Method(_STA, 0, NotSerialized) {
>>> +                Store(VGIA, Local0)
>>> +                If (LEqual(Local0, Zero)) {
>>> +                    Return (0x00)
>>> +                } Else {
>>> +                    Return (0x0F)
>>> +                }
>>> +            }
>>> +
>>> +            Method(ADDR, 0, Serialized) {
>>> +                Store(Package(2) { }, Local0)
>>> +                Store(VGIA, Index(Local0, 0))
>>> +                Store(0x0000, Index(Local0, 1))
>>> +                return (Local0)
>>> +            }
>>> +        }
>>> +    }
>>> +
>>
>> Please either put this in the DSDT, or omit the Device altogether if you
>> put it in the SSDT and there is no VMGID device.
> 
> I'm not sure I understand this comment. I've put the new device in the
> SSDT table (like pvpanic) and add a _STA method which disable the device
> if no GUID's address is set (VGIA). The device doesn't show in the
> Device Manager if it was not added using the command line.

We are still in the process of defining which devices/methods go in the
DSDT and which go in the SSDT.  We had bad experiences with ACPI table
migration in 2.1, and one plan to fix them is the following:

* the DSDT should always be the same size no matter what command line
options are there

* the SSDT should have the exact same content (byte-for-byte) for
different versions of QEMU, with the same command line options
(including the machine type).

Right now your code obeys the first rule, not the second rule, so it
should add the device to the DSDT.

BTW, which events would cause the ID to change?  How should live cloning
(or revert to a disk+RAM snapshot) be implemented by layers above QEMU
for the VM gen ID to be patched?  Can you add something to docs/ about it?

Also, how does this ID compare to the UUID in the DMI info (-uuid)?

Paolo

Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 12/08/2014 10:02, Gal Hammer ha scritto:
>> Hi,
>> 
>> On 10/08/2014 20:22, Paolo Bonzini wrote:
>> 
>>> Il 10/08/2014 13:32, Gal Hammer ha scritto:
>>>> Based on Microsoft's sepecifications (paper can be dowloaded from
>>>> http://go.microsoft.com/fwlink/?LinkId=260709), add a device
>>>> description to the SSDT ACPI table.
>>>>
>>>> The GUID is set using a new "-vmgenid" command line parameter.
>>>>
>>>> Signed-off-by: Gal Hammer <ghammer@redhat.com>
>>>> ---
>>>>   hw/i386/acpi-build.c  | 23 +++++++++++++++++++++++
>>>>   hw/i386/ssdt-misc.dsl | 33 +++++++++++++++++++++++++++++++++
>>>>   qemu-options.hx       |  9 +++++++++
>>>>   vl.c                  | 11 +++++++++++
>>>>   4 files changed, 76 insertions(+)
>>>
>>> Please make this a new device (like pvpanic), instead of adding a new
>>> command-line option.
>> 
>> There is a problem with this request. I don't want to use ISA because it
>> is obsolete, PCI is overkill for such a device and a SYSBUS (like HPET)
>> device doesn't effect the command line options.
>> 
>> Did I miss something in SYSBUS and that's was the reason it didn't
>> appear in the "-device ?" list?
>
> For a sysbus device, you can override the
> cannot_instantiate_with_device_add_yet field of DeviceClass in your
> class_init function.

Correct.

Sysbus devices are not available with device_add / -device by default,
because to actually work, they commonly require code to connect them to
other devices.  A sysbus device that doesn't need such connections can
be made available with device_add / -device in the way Paolo described.

[...]

Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.

[Gal Hammer]

On 17/08/2014 12:49, Paolo Bonzini wrote:
> Il 12/08/2014 10:02, Gal Hammer ha scritto:
>> Hi,
>>
>> On 10/08/2014 20:22, Paolo Bonzini wrote:
>>
>>> Il 10/08/2014 13:32, Gal Hammer ha scritto:
>>>> Based on Microsoft's sepecifications (paper can be dowloaded from
>>>> http://go.microsoft.com/fwlink/?LinkId=260709), add a device
>>>> description to the SSDT ACPI table.
>>>>
>>>> The GUID is set using a new "-vmgenid" command line parameter.
>>>>
>>>> Signed-off-by: Gal Hammer <ghammer@redhat.com>
>>>> ---
>>>>    hw/i386/acpi-build.c  | 23 +++++++++++++++++++++++
>>>>    hw/i386/ssdt-misc.dsl | 33 +++++++++++++++++++++++++++++++++
>>>>    qemu-options.hx       |  9 +++++++++
>>>>    vl.c                  | 11 +++++++++++
>>>>    4 files changed, 76 insertions(+)
>>>
>>> Please make this a new device (like pvpanic), instead of adding a new
>>> command-line option.
>>
>> There is a problem with this request. I don't want to use ISA because it
>> is obsolete, PCI is overkill for such a device and a SYSBUS (like HPET)
>> device doesn't effect the command line options.
>>
>> Did I miss something in SYSBUS and that's was the reason it didn't
>> appear in the "-device ?" list?
>
> For a sysbus device, you can override the
> cannot_instantiate_with_device_add_yet field of DeviceClass in your
> class_init function.
>
>>>>
>>>> +    Scope(\_SB) {
>>>> +
>>>> +        Device(VMGI) {
>>>> +            Name(_HID, "QEMU0002")
>>>> +            Name(_CID, "VM_Gen_Counter")
>>>> +            Name(_DDN, "VM_Gen_Counter")
>>>> +
>>>> +            ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr
>>>> +            Name(VGIA, 0x12345678)
>>>> +
>>>> +            ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid
>>>> +            Name(VGID, Buffer(16) {
>>>> +                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>>>> +                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 })
>>>> +
>>>> +            Method(_STA, 0, NotSerialized) {
>>>> +                Store(VGIA, Local0)
>>>> +                If (LEqual(Local0, Zero)) {
>>>> +                    Return (0x00)
>>>> +                } Else {
>>>> +                    Return (0x0F)
>>>> +                }
>>>> +            }
>>>> +
>>>> +            Method(ADDR, 0, Serialized) {
>>>> +                Store(Package(2) { }, Local0)
>>>> +                Store(VGIA, Index(Local0, 0))
>>>> +                Store(0x0000, Index(Local0, 1))
>>>> +                return (Local0)
>>>> +            }
>>>> +        }
>>>> +    }
>>>> +
>>>
>>> Please either put this in the DSDT, or omit the Device altogether if you
>>> put it in the SSDT and there is no VMGID device.
>>
>> I'm not sure I understand this comment. I've put the new device in the
>> SSDT table (like pvpanic) and add a _STA method which disable the device
>> if no GUID's address is set (VGIA). The device doesn't show in the
>> Device Manager if it was not added using the command line.
>
> We are still in the process of defining which devices/methods go in the
> DSDT and which go in the SSDT.  We had bad experiences with ACPI table
> migration in 2.1, and one plan to fix them is the following:
>
> * the DSDT should always be the same size no matter what command line
> options are there
>
> * the SSDT should have the exact same content (byte-for-byte) for
> different versions of QEMU, with the same command line options
> (including the machine type).
>
> Right now your code obeys the first rule, not the second rule, so it
> should add the device to the DSDT.

Are you sure about selecting the DSDT? I don't see anyone else is using 
the ACPI_EXTRACT_NAME_* macros in the DSDT table (and I keep crashing my 
guest, but ignore it for now ;-)).

> BTW, which events would cause the ID to change?  How should live cloning
> (or revert to a disk+RAM snapshot) be implemented by layers above QEMU
> for the VM gen ID to be patched?  Can you add something to docs/ about it?

The VGID is expected to change when executing a VM with the -snapshot 
option, when a VM is restored from a backup or when it is imported, 
copied or cloned. So I would say it is a management's call.

I think that the Microsoft's document describes the requirements better 
than me :-).

> Also, how does this ID compare to the UUID in the DMI info (-uuid)?

The -uuid is not expected to change after the VM was created. Unlike the 
-vmgenid that is designed to give the guest OS a notification that a 
change has occurred. Microsoft, as an example, writes that is can be use 
for a safer cryptographic software.

> Paolo
>

     Gal.

Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.

[Paolo Bonzini]

Il 01/09/2014 09:20, Gal Hammer ha scritto:
>>
>> We are still in the process of defining which devices/methods go in the
>> DSDT and which go in the SSDT.  We had bad experiences with ACPI table
>> migration in 2.1, and one plan to fix them is the following:
>>
>> * the DSDT should always be the same size no matter what command line
>> options are there
>>
>> * the SSDT should have the exact same content (byte-for-byte) for
>> different versions of QEMU, with the same command line options
>> (including the machine type).
>>
>> Right now your code obeys the first rule, not the second rule, so it
>> should add the device to the DSDT.
> 
> Are you sure about selecting the DSDT? I don't see anyone else is using
> the ACPI_EXTRACT_NAME_* macros in the DSDT table (and I keep crashing my
> guest, but ignore it for now ;-)).

There is one user:

acpi-dsdt-isa.dsl:        ACPI_EXTRACT_NAME_BYTE_CONST DSDT_APPLESMC_STA

>> BTW, which events would cause the ID to change?  How should live cloning
>> (or revert to a disk+RAM snapshot) be implemented by layers above QEMU
>> for the VM gen ID to be patched?  Can you add something to docs/ about
>> it?
> 
> The VGID is expected to change when executing a VM with the -snapshot
> option, when a VM is restored from a backup or when it is imported,
> copied or cloned. So I would say it is a management's call.

Ok, got it.

So to support migration (which includes reverting to an earlier disk+RAM
snapshot) you just need to ensure the VGID is patched accordingly.
Whether VGID _will_ be different or not, that's management's call.

> I think that the Microsoft's document describes the requirements better
> than me :-).
> 
>> Also, how does this ID compare to the UUID in the DMI info (-uuid)?
> 
> The -uuid is not expected to change after the VM was created. Unlike the
> -vmgenid that is designed to give the guest OS a notification that a
> change has occurred. Microsoft, as an example, writes that is can be use
> for a safer cryptographic software.

I would say that cloning should change the UUID (and the VMGID).

Paolo

Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.

[Gal Hammer]

On 01/09/2014 11:57, Paolo Bonzini wrote:
> Il 01/09/2014 09:20, Gal Hammer ha scritto:
>>>
>>> We are still in the process of defining which devices/methods go in the
>>> DSDT and which go in the SSDT.  We had bad experiences with ACPI table
>>> migration in 2.1, and one plan to fix them is the following:
>>>
>>> * the DSDT should always be the same size no matter what command line
>>> options are there
>>>
>>> * the SSDT should have the exact same content (byte-for-byte) for
>>> different versions of QEMU, with the same command line options
>>> (including the machine type).
>>>
>>> Right now your code obeys the first rule, not the second rule, so it
>>> should add the device to the DSDT.
>>
>> Are you sure about selecting the DSDT? I don't see anyone else is using
>> the ACPI_EXTRACT_NAME_* macros in the DSDT table (and I keep crashing my
>> guest, but ignore it for now ;-)).
>
> There is one user:
>
> acpi-dsdt-isa.dsl:        ACPI_EXTRACT_NAME_BYTE_CONST DSDT_APPLESMC_STA

Found it after I've stopped looking only at the acpi-dsdt.dsl file.

>>> BTW, which events would cause the ID to change?  How should live cloning
>>> (or revert to a disk+RAM snapshot) be implemented by layers above QEMU
>>> for the VM gen ID to be patched?  Can you add something to docs/ about
>>> it?
>>
>> The VGID is expected to change when executing a VM with the -snapshot
>> option, when a VM is restored from a backup or when it is imported,
>> copied or cloned. So I would say it is a management's call.
>
> Ok, got it.
>
> So to support migration (which includes reverting to an earlier disk+RAM
> snapshot) you just need to ensure the VGID is patched accordingly.
> Whether VGID _will_ be different or not, that's management's call.
>
>> I think that the Microsoft's document describes the requirements better
>> than me :-).
>>
>>> Also, how does this ID compare to the UUID in the DMI info (-uuid)?
>>
>> The -uuid is not expected to change after the VM was created. Unlike the
>> -vmgenid that is designed to give the guest OS a notification that a
>> change has occurred. Microsoft, as an example, writes that is can be use
>> for a safer cryptographic software.
>
> I would say that cloning should change the UUID (and the VMGID).

Again, that's a management call as well. One might choose not to change 
the BIOS UUID when cloning the machine in order to prevent Windows from 
trying to re-activate itself (or any other licensed software for that 
matter).

> Paolo
>

A V2 of the patch was send to the list.

     Gal.