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

[Gal Hammer <ghammer@redhat.com>]

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.