qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] docs: describe QEMU's VMGenID design


From: Eric Blake
Subject: Re: [Qemu-devel] [RFC] docs: describe QEMU's VMGenID design
Date: Tue, 1 Sep 2015 13:47:17 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

On 08/28/2015 02:18 PM, Laszlo Ersek wrote:
> Cc: Paolo Bonzini <address@hidden>
> Cc: Gal Hammer <address@hidden>
> Cc: Igor Mammedov <address@hidden>
> Cc: "Michael S. Tsirkin" <address@hidden>
> Signed-off-by: Laszlo Ersek <address@hidden>
> ---
> 
> Notes:
>     This is based on the super long private email discussion we had two
>     months ago, plus on the IRL discussion between Michael and myself @ the
>     KVM Forum 2015.
> 
>  docs/specs/vmgenid.txt | 343 
> +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 343 insertions(+)
>  create mode 100644 docs/specs/vmgenid.txt
> 

Grammar review; I may miss some technical details.

> diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt
> new file mode 100644
> index 0000000..d4bf132
> --- /dev/null
> +++ b/docs/specs/vmgenid.txt
> @@ -0,0 +1,343 @@
> +Virtual Machine Generation ID Device
> +====================================

Is it worth a preamble giving a specific copyright/license for this
file? Without one, it inherits the default GPLv2+ from the top-level,
and there are some people (although I'm not one) that worry that an
independent implementation of a GPL'd spec must itself be GPL (that is,
specifically choosing a looser license for the spec may make it more
amenable to the OVMF folks).

> +
> +The Microsoft specification entitled "Virtual Machine Generation ID",
> +maintained at <http://go.microsoft.com/fwlink/?LinkId=260709>, defines an 
> ACPI
> +feature that allows the guest OSPM to recognize when it has been returned "to
> +an earlier point in time", eg. by restoral from snapshot, or by incoming

s/eg./e.g./
s/restoral/restoring/

> +migration. Quoting the spec,

[I'm not sure that incoming migration is necessarily returning to an
earlier point in time; although I can certainly see that being the case
when repeatedly doing incoming migration from the same file]

> +
> +    The virtual machine generation ID is a feature whereby the virtual 
> machines

s/machines/machine's/ [oh wait, you're quoting Microsoft's poor grammar]

> +    BIOS will expose a new ID. This is a 128-bit, cryptographically random
> +    integer value identifier that will be different every time the virtual
> +    machine executes from a different configuration file-such as executing 
> from
> +    a recovered snapshot, or executing after restoring from backup. [...]
> +
> +The document you are reading now extracts the requirements set forth by the
> +VMGenID spec for hypervisors that intend to provide the feature, and 
> describes
> +QEMU's implementation. The design below targets both SeaBIOS and OVMF as
> +compatible guest firmwares, without any changes to either of them.
> +

Otherwise, I didn't spot any obvious wording problems.

-- 
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]