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

["Catangiu, Adrian Costin" via <qemu-devel@nongnu.org>]

[-- Attachment #1: Type: text/plain, Size: 4121 bytes --]

+ 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
underlyingVM or container goes through a snapshot restore event which is
otherwisetransparent 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
>> https://lkml.org/lkml/2018/3/1/498
> Eric
>



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.

[-- Attachment #2: Type: text/html, Size: 7257 bytes --]