On 02/05/17 10:12, b...@skyportsystems.com wrote:
> From: Ben Warren <b...@skyportsystems.com>
>
> This implements the VM Generation ID feature by passing a 128-bit
> GUID to the guest via a fw_cfg blob.
> Any time the GUID changes, an ACPI notify event is sent to the guest
>
> The user interface is a simple device with one parameter:
> - guid (string, must be "auto" or in UUID format
> xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
>
> Signed-off-by: Ben Warren <b...@skyportsystems.com>
> ---
> default-configs/i386-softmmu.mak | 1 +
> default-configs/x86_64-softmmu.mak | 1 +
> hw/acpi/Makefile.objs | 1 +
> hw/acpi/vmgenid.c | 206
> +++++++++++++++++++++++++++++++++++
> hw/i386/acpi-build.c | 10 ++
> include/hw/acpi/acpi_dev_interface.h | 1 +
> include/hw/acpi/vmgenid.h | 37 +++++++
> 7 files changed, 257 insertions(+)
> create mode 100644 hw/acpi/vmgenid.c
> create mode 100644 include/hw/acpi/vmgenid.h
[snip]
> +static void vmgenid_device_class_init(ObjectClass *klass, void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> +
> + dc->vmsd = &vmstate_vmgenid;
> +}
I think in this function, you should set up a dc->realize member as
well. And, in that dc->realize member, you should call
qemu_register_reset().
Because, as it stands now, the "vgia_le" field is not cleared on reset.
It should be; when the guest is rebooted, we should forget any address
returned by its firmware.
In this reset callback, you should also clear the (new) latch that
tracks whether the "vmgenid" blob was selected since reset. (The latch
is for approach (iii) against the race.)
Thanks,
Laszlo
