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.