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).