[Top][All Lists]

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

Re: [PATCH v3] drivers/virt: vmgenid: add vm generation id driver

From: Catangiu, Adrian Costin
Subject: Re: [PATCH v3] drivers/virt: vmgenid: add vm generation id driver
Date: Mon, 11 Jan 2021 09:35:03 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

+ Eric W. Biederman

Eric's email was filtered by my server for some reason so I can't directly reply to it, this is the closest thread relative I could answer on.

On 01/12/2020 12:00, Eric W. Biederman wrote:

On 27.11.20 19:26, Catangiu, Adrian Costin wrote:
- Background

The VM Generation ID is a feature defined by Microsoft (paper:
http://go.microsoft.com/fwlink/?LinkId=260709) and supported by
multiple hypervisor vendors.

The feature is required in virtualized environments by apps that work
with local copies/caches of world-unique data such as random values,
uuids, monotonically increasing counters, etc.
Such apps can be negatively affected by VM snapshotting when the VM
is either cloned or returned to an earlier point in time.

How does this differ from /proc/sys/kernel/random/boot_id?
The boot_id only changes at OS boot whereas we need the generation id to
change _while_ the system/guest-os is running - generation changes because
underlying VM or container goes through a snapshot restore event which is
otherwise transparent to guest system.

The VM Generation ID is a simple concept meant to alleviate the issue
by providing a unique ID that changes each time the VM is restored
from a snapshot. The hw provided UUID value can be used to
differentiate between VMs or different generations of the same VM.

Does the VM generation ID change in a running that effectively things it
is running?
Yes, the generation id changes while guest OS is running, the generation
change itself is what lets the guest OS and guest userspace know there's
been a VM or container snapshot restore event.

- Problem

The VM Generation ID is exposed through an ACPI device by multiple
hypervisor vendors but neither the vendors or upstream Linux have no
default driver for it leaving users to fend for themselves.

Furthermore, simply finding out about a VM generation change is only
the starting point of a process to renew internal states of possibly
multiple applications across the system. This process could benefit
from a driver that provides an interface through which orchestration
can be easily done.

- Solution

This patch is a driver that exposes a monotonic incremental Virtual
Machine Generation u32 counter via a char-dev FS interface.
Earlier it was a UUID now it is 32bit number?
The generation id exposed to userspace is a 32bit monotonic incremental
counter. This counter is internally driven by the acpi vmgenid device. The
128-bit vmgenid-device-provided UUID is only used internally by the driver.

I will make all of this clearer in the next patch version.

The FS
interface provides sync and async VmGen counter updates notifications.
It also provides VmGen counter retrieval and confirmation mechanisms.

The generation counter and the interface through which it is exposed
are available even when there is no acpi device present.

When the device is present, the hw provided UUID is not exposed to
userspace, it is internally used by the driver to keep accounting for
the exposed VmGen counter. The counter starts from zero when the
driver is initialized and monotonically increments every time the hw
UUID changes (the VM generation changes).
On each hw UUID change, the new hypervisor-provided UUID is also fed
to the kernel RNG.
Should this be a hotplug even rather than a new character device?

Without plugging into udev and the rest of the hotplug infrastructure
I suspect things will be missed.
That's a good idea, I will look into it.

If there is no acpi vmgenid device present, the generation changes are
not driven by hw vmgenid events but can be driven by software through
a dedicated driver ioctl.

This patch builds on top of Or Idgar <oridgar@gmail.com>'s proposal

Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.

reply via email to

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