Re: [PATCH 0/2] vmgenid: add generation counter

[Chalios, Babis]

Hi Daniel,

On 3/8/22 18:26, Daniel P. Berrangé wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you can confirm the sender and know the 
> content is safe.
>
>
>
> On Wed, Aug 03, 2022 at 03:41:45PM +0200, bchalios@amazon.es wrote:
> > From: Babis Chalios <bchalios@amazon.es>
> >
> > VM generation ID exposes a GUID inside the VM which changes every time a
> > VM restore is happening. Typically, this GUID is used by the guest
> > kernel to re-seed its internal PRNG. As a result, this value cannot be
> > exposed in guest user-space as a notification mechanism for VM restore
> > events.
> >
> > This patch set extends vmgenid to introduce a 32 bits generation counter
> > whose purpose is to be used as a VM restore notification mechanism for
> > the guest user-space.
> >
> > It is true that such a counter could be implemented entirely by the
> > guest kernel, but this would rely on the vmgenid ACPI notification to
> > trigger the counter update, which is inherently racy. Exposing this
> > through the monitor allows the updated value to be in-place before
> > resuming the vcpus, so interested user-space code can (atomically)
> > observe the update without relying on the ACPI notification.
> The VM generation ID feature in QEMU is implementing a spec defined
> by Microsoft. It is implemented in HyperV, VMWare, QEMU and possibly
> more. This series is proposing a QEMU specific variant, which means
> Linux running on all these other hypervisor platforms won't benefit
> from the change. If the counter were provided entirely in the guest
> kernel, then it works across all hypervisors.
>
> It feels like the kernel ought to provide an implementation itself
> as a starting point, with this QEMU change merely being an optional
> enhancement to close the race window.
>
> Ideally there would be someone at Microsoft we could connect with to
> propose they include this feature in a VM Gen ID spec update, but I
> don't personally know who to contact about that kind of thing. A
> spec update would increase chances that this change gets provieded
> across all hypervisors.

You are right, this *is* out-of-spec. The approach here is based on various
discussions happened last year when we first tried to upstream and more
recently when vmgenid landed in Linux. I find that this summary:
https://lkml.org/lkml/2022/3/1/693 quite to the point. (CCing Jason to
have his take on the matter).

This series comes together with a Linux counterpart:
https://lkml.org/lkml/2022/8/3/563, where the generation counter is
exposed to user-space as a misc device. There, I tried to make the
generation counter "optional", in the sense that if it is not there, the
ACPI device should not fail, exactly because, for the moment, this is
not in the spec and hypervisors might not want to implement it.

However, I think that changing the spec will take time and this is a
real issue affecting real use-cases, so we should start from somewhere.

Cheers,
Babis


> With regards,
> Daniel
> --
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Amazon Spain Services sociedad limitada unipersonal, Calle Ramirez de Prado 5, 
28045 Madrid. Registro Mercantil de Madrid . Tomo 22458 . Folio 102 . Hoja 
M-401234 . CIF B84570936