On Thu, Aug 04, 2022 at 11:54:05AM +0200, Chalios, Babis wrote: > 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, bchal...@amazon.es wrote: > > > From: Babis Chalios <bchal...@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.
I know a spec change can take time, but has there even been any effort at all to try to start that action since first discussed a year ago ? If these race condition issues are supposedly so serious that we need to do this without waiting for a spec, then what is the answer for the masses of users running Linux on VMware or HyperV/Azure ? 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 :|