[v5,03/10] docs: VM Generation ID device description

From: Ben Warren <ben@skyportsystems.com>

This patch is based off an earlier version by
Gal Hammer (ghammer@redhat.com)

Requirements section, ASCII diagrams and overall help
provided by Laszlo Ersek (lersek@redhat.com)

Signed-off-by: Gal Hammer <ghammer@redhat.com>
Signed-off-by: Ben Warren <ben@skyportsystems.com>
---
 docs/specs/vmgenid.txt | 239 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 docs/specs/vmgenid.txt

On 02/05/2017 03:11 AM, ben@skyportsystems.com wrote:
> From: Ben Warren <ben@skyportsystems.com>
> 
> This patch is based off an earlier version by
> Gal Hammer (ghammer@redhat.com)
> 
> Requirements section, ASCII diagrams and overall help
> provided by Laszlo Ersek (lersek@redhat.com)
> 
> Signed-off-by: Gal Hammer <ghammer@redhat.com>
> Signed-off-by: Ben Warren <ben@skyportsystems.com>
> ---
>  docs/specs/vmgenid.txt | 239 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 239 insertions(+)
>  create mode 100644 docs/specs/vmgenid.txt
> 

> +

> +
> +Design Details:
> +---------------
> +
> +Requirements R1a through R1e dicate that the memory holding the

s/dicate/dictate/

> +VM Generation ID must be allocated and owned by the guest operating system,

> +
> +GUID Storage Format:
> +--------------------
> +
> +In order to work with OVMF "SDT Header Probe Supressor", the contents of

s/Supressor/Suppressor/

> +the vmgenid fw_cfg blob are not simply a 128-bit GUID.  There is also
> +significant padding in order to align and fill a memory page, as shown in the
> +following diagram:
> +
> ++----------------------------------+
> +| SSDT with OEM Table ID = VMGENID |
> ++----------------------------------+
> +| ...                              |       TOP OF PAGE
> +| VGIA dword object ---------------|-----> +---------------------------+
> +| ...                              |       | fw-allocated array for    |
> +| _STA method referring to VGIA    |       | "etc/vmgenid"        |

Inconsistent whitespace

On 02/05/17 10:11, ben@skyportsystems.com wrote:
> From: Ben Warren <ben@skyportsystems.com>
> 
> This patch is based off an earlier version by
> Gal Hammer (ghammer@redhat.com)
> 
> Requirements section, ASCII diagrams and overall help
> provided by Laszlo Ersek (lersek@redhat.com)
> 
> Signed-off-by: Gal Hammer <ghammer@redhat.com>
> Signed-off-by: Ben Warren <ben@skyportsystems.com>
> ---
>  docs/specs/vmgenid.txt | 239 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 239 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..d36f8bd
> --- /dev/null
> +++ b/docs/specs/vmgenid.txt
> @@ -0,0 +1,239 @@
> +VIRTUAL MACHINE GENERATION ID
> +=============================
> +
> +Copyright (C) 2016 Red Hat, Inc.
> +Copyright (C) 2017 Skyport Systems, Inc.
> +
> +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,
> +referred to as a Globally Unique Identifier, or GUID.
> +
> +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).  The
> +guest operating system notices the change, and is then able to react as
> +appropriate by marking its copies of distributed databases as dirty,
> +re-initializing its random number generator etc.
> +
> +
> +Requirements
> +------------
> +
> +These requirements are extracted from the "How to implement virtual machine
> +generation ID support in a virtualization platform" section of the
> +specification, dated August 1, 2012.
> +
> +
> +The document may be found on the web at:
> +  http://go.microsoft.com/fwlink/?LinkId=260709
> +
> +R1a. The generation ID shall live in an 8-byte aligned buffer.
> +
> +R1b. The buffer holding the generation ID shall be in guest RAM, ROM, or device
> +     MMIO range.
> +
> +R1c. The buffer holding the generation ID shall be kept separate from areas
> +     used by the operating system.
> +
> +R1d. The buffer shall not be covered by an AddressRangeMemory or
> +     AddressRangeACPI entry in the E820 or UEFI memory map.
> +
> +R1e. The generation ID shall not live in a page frame that could be mapped with
> +     caching disabled. (In other words, regardless of whether the generation ID
> +     lives in RAM, ROM or MMIO, it shall only be mapped as cacheable.)
> +
> +R2 to R5. [These AML requirements are isolated well enough in the Microsoft
> +          specification for us to simply refer to them here.]
> +
> +R6. The hypervisor shall expose a _HID (hardware identifier) object in the
> +    VMGenId device's scope that is unique to the hypervisor vendor.
> +
> +
> +QEMU Implementation
> +-------------------
> +
> +The above-mentioned specification does not dictate which ACPI descriptor table
> +will contain the VM Generation ID device.  Other implementations (Hyper-V and
> +Xen) put it in the main descriptor table (Differentiated System Description
> +Table or DSDT).  For ease of debugging and implementation, we have decided to
> +put it in its own Secondary System Description Table, or SSDT.
> +
> +The following is a dump of the contents from a running system:
> +
> +# iasl -p ./SSDT -d /sys/firmware/acpi/tables/SSDT
> +
> +Intel ACPI Component Architecture
> +ASL+ Optimizing Compiler version 20150717-64
> +Copyright (c) 2000 - 2015 Intel Corporation
> +
> +Reading ACPI table from file /sys/firmware/acpi/tables/SSDT - Length
> +00000198 (0x0000C6)
> +ACPI: SSDT 0x0000000000000000 0000C6 (v01 BOCHS  VMGENID  00000001 BXPC
> +00000001)
> +Acpi table [SSDT] successfully installed and loaded
> +Pass 1 parse of [SSDT]
> +Pass 2 parse of [SSDT]
> +Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
> +
> +Parsing completed
> +Disassembly completed
> +ASL Output:    ./SSDT.dsl - 1631 bytes
> +# cat SSDT.dsl
> +/*
> + * Intel ACPI Component Architecture
> + * AML/ASL+ Disassembler version 20150717-64
> + * Copyright (c) 2000 - 2015 Intel Corporation
> + *
> + * Disassembling to symbolic ASL+ operators
> + *
> + * Disassembly of /sys/firmware/acpi/tables/SSDT, Sun Feb  5 00:19:37 2017
> + *
> + * Original Table Header:
> + *     Signature        "SSDT"
> + *     Length           0x000000CA (202)
> + *     Revision         0x01
> + *     Checksum         0x4B
> + *     OEM ID           "BOCHS "
> + *     OEM Table ID     "VMGENID"
> + *     OEM Revision     0x00000001 (1)
> + *     Compiler ID      "BXPC"
> + *     Compiler Version 0x00000001 (1)
> + */
> +DefinitionBlock ("/sys/firmware/acpi/tables/SSDT.aml", "SSDT", 1, "BOCHS ",
> +"VMGENID", 0x00000001)
> +{
> +    Name (VGIA, 0x07FFF000)
> +    Scope (\_SB)
> +    {
> +        Device (VGEN)
> +        {
> +            Name (_HID, "QEMUVGID")  // _HID: Hardware ID
> +            Name (_CID, "VM_Gen_Counter")  // _CID: Compatible ID
> +            Name (_DDN, "VM_Gen_Counter")  // _DDN: DOS Device Name
> +            Method (_STA, 0, NotSerialized)  // _STA: Status
> +            {
> +                Local0 = 0x0F
> +                If ((VGIA == Zero))
> +                {
> +                    Local0 = Zero
> +                }
> +
> +                Return (Local0)
> +            }
> +
> +            Method (ADDR, 0, NotSerialized)
> +            {
> +                Local0 = Package (0x02) {}
> +                Index (Local0, Zero) = (VGIA + 0x28)
> +                Index (Local0, One) = Zero
> +                Return (Local0)
> +            }
> +        }
> +    }
> +
> +    Method (\_GPE._E05, 0, NotSerialized)  // _Exx: Edge-Triggered GPE
> +    {
> +        Notify (\_SB.VGEN, 0x80) // Status Change
> +    }
> +}
> +
> +
> +Design Details:
> +---------------
> +
> +Requirements R1a through R1e dicate that the memory holding the
> +VM Generation ID must be allocated and owned by the guest operating system,

s/guest operating system/guest firmware/, in my opinion. Do you agree?

> +in this case BIOS or UEFI.  However, to be useful, QEMU must be able to
> +change the contents of the memory at runtime, specifically when starting a
> +backed-up or snapshotted image.  In order to do this, QEMU must know the
> +address that has been allocated.
> +
> +The mechanism chosen for this memory sharing is writeable fw_cfg blobs.
> +These are in-memory data structures that are visible to both QEMU and guests,
> +and are addressable as files.

The expression "in-memory data structures" is misleading; they need not
exist in complete (or any) form in guest RAM.

I recommend "data objects" instead (and maybe reference
"docs/specs/fw_cfg.txt").

Also, "addressable as files" is too generic, we don't have random
access. I'd say "addressable as sequential files" (we have rewind (by
way of select), skip, read, and write).

> +
> +Two fw_cfg blobs are used in this case:
> +
> +/etc/vmgenid      - contains the actual VM Generation ID GUID
> +                  - read-only to the guest
> +/etc/vmgenid_addr - contains the address of the GUID

Please replace "address of the GUID" with "address of the downloaded
vmgenid blob".

> +                  - writeable by the guest
> +
> +
> +QEMU sends the following commands to the guest at startup:
> +
> +1. Allocate memory for vmgenid fw_cfg blob.
> +2. Write the address of vmgenid into the SSDT (VGIA ACPI variable as
> +   shown above in the iasl dump).  Note that this change is not propagated
> +   back to QEMU.
> +3. Write the address of vmgenid back to QEMU's copy of vmgenid_addr
> +   via the fw_cfg DMA interface.

Please drop "QEMU's copy of".

(All fw_cfg blobs are owned by QEMU, and for some of those, it makes
sense for the firmware to have a copy. In this case, the firmware has no
copy, and QEMU's "copy" is the original thing.)

> +
> +After step 3, QEMU is able to update the contents of vmgenid at will.
> +
> +Since BIOS or UEFI does not necessarily run when we wish to change the GUID,
> +the value of VGIA is persisted via the VMState mechanism.
> +
> +As spelled out in the specification, any change to the GUID executes an
> +ACPI notification.  The exact handler to use is not specified, so the vmgenid
> +device uses the first unused one:  \_GPE._E05.
> +
> +
> +Endian-ness Considerations:
> +---------------------------
> +
> +Although not specified in Microsoft's document, it is assumed that the
> +device is expected to use little-endian format.
> +
> +All GUID passed in via command line or monitor are treated as big-endian.
> +GUID values displayed via monitor are shown in big-endian format.
> +
> +
> +GUID Storage Format:
> +--------------------
> +
> +In order to work with OVMF "SDT Header Probe Supressor", the contents of

s/work with/implement an/

> +the vmgenid fw_cfg blob are not simply a 128-bit GUID.  There is also
> +significant padding in order to align and fill a memory page, as shown in the
> +following diagram:
> +
> ++----------------------------------+
> +| SSDT with OEM Table ID = VMGENID |
> ++----------------------------------+
> +| ...                              |       TOP OF PAGE
> +| VGIA dword object ---------------|-----> +---------------------------+
> +| ...                              |       | fw-allocated array for    |
> +| _STA method referring to VGIA    |       | "etc/vmgenid"        |
> +| ...                              |       +---------------------------+
> +| ADDR method referring to VGIA    |       |  0: OVMF SDT Header probe |
> +| ...                              |       |     suppressor            |
> ++----------------------------------+       | 36: padding for 8-byte    |
> +                                           |     alignment             |
> +                                           | 40: GUID                  |
> +                                           | 56: padding to page size  |
> +                                           +---------------------------+
> +                                           END OF PAGE

Hahaha, Laszlo cannot multiply. In my previous review I wrote "48" as
start offset for "padding to page size", which implies an 8-byte
(64-bit) GUID... In fact the GUID takes 128 bits, hence 16 bytes. Good
catch! :)

> +
> +
> +Device Usage:
> +-------------
> +
> +The device has one property, which can be set using the command line
> +argument or the QMP interface:
> +
> + guid - sets the value of the GUID.  A special value "auto" instructs
> +        QEMU to generate a new random GUID.
> +
> +For example:
> +
> + QEMU  -device vmgenid,guid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87"
> +
> +Or to change guid in runtime use:
> +
> + set-vm-generation-id guid=124e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87
> + set-vm-generation-id guid=auto
> 

I like this version very much. Please fix up the warts identified by
Eric and myself, and then you can add my

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

for the next version.

(If you change other parts as well, then please don't add my R-b.)

Thank you!
Laszlo

On 02/05/17 10:11, ben@skyportsystems.com wrote:

> +Or to change guid in runtime use:
> +
> + set-vm-generation-id guid=124e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87
> + set-vm-generation-id guid=auto
> 

Please drop the "guid=" prefix from the examples; the HMP command
doesn't need it / chokes on it. It only takes "auto" or a UUID.

Thanks
Laszlo