[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID d
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device. |
Date: |
Mon, 01 Sep 2014 10:57:14 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 |
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