qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V14 1/3] docs: vm generation id device's descrip


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH V14 1/3] docs: vm generation id device's description
Date: Wed, 04 Mar 2015 12:57:14 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 03/03/2015 09:18 AM, Igor Mammedov wrote:
> From: Gal Hammer <address@hidden>
> 
> Signed-off-by: Gal Hammer <address@hidden>
> Signed-off-by: Igor Mammedov <address@hidden>
> ---
> v2:
>  - ammend doc since no more MMIO occupied by vmgenid

s/ammend/amend/ (but this isn't part of the commit message)

>    device and device became PCIDevice
> ---
>  docs/specs/vmgenid.txt | 36 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
>  create mode 100644 docs/specs/vmgenid.txt
> 
> diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt
> new file mode 100644
> index 0000000..718850a
> --- /dev/null
> +++ b/docs/specs/vmgenid.txt
> @@ -0,0 +1,36 @@
> +VIRTUAL MACHINE GENERATION ID
> +=============================
> +
> +Copyright (C) 2014 Red Hat, Inc.

Might also want to claim 2015, as you have redesigned this since 2014.

> +
> +This work is licensed under the terms of the GNU GPL, version 2 or later.
> +See the COPYING file in the top-level directory.
> +
> +===
> +
> +The VM generation ID (vmgenid) device is an emulated device which
> +exposes a 128-bit, cryptographically random, integer value identifier.
> +This allows management applications (e.g. libvirt) to notify the guest
> +operating system when the virtual machine is executed with a different
> +configuration (e.g. snapshot execution or creation from a template).

It sounds like management applications (and not qemu) is responsible for
populating the 128 bits with cryptographically random data.  That is, if
libvirt fails to put truly random data in the memory via qom-set, the
bug would be in libvirt and not qemu.  Correct?  If so, should this doc
make it explicit that qemu is leaving it up to management to write
correct data into the memory?

> +
> +This is specified on the web at: 
> http://go.microsoft.com/fwlink/?LinkId=260709

How sure are we that this link won't go stale in the future? Should we
archive a copy of it somewhere on a site we control?

> +
> +---
> +
> +The vmgenid device is a PCI device with the following ACPI ID: "QEMU0003".
> +
> +The device has a "vmgenid.uuid" property, which can be set using
> +the command line argument or the QMP interface.
> +For example:
> +QEMU  -device vmgenid,id=FOO,uuid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87"
> +
> +Or to change uuid in runtime use:
> + qom-set "/machine/peripheral/FOO.uuid" 
> "124e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87"
> +
> +According to the specification, any change to the GUID executes an
> +ACPI notification. The vmgenid device triggers the \_GPE._E00 handler
> +which executes the ACPI Notify operation.
> +
> +Although not specified in Microsoft's document, it is assumed that the
> +device is expected to use the little-endian system.
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]