Re: [RFC PATCH 0/4] vmclock: add support for VM generation counter and notifications

[David Woodhouse <dwmw2@infradead.org>]

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

On Mon, 2025-12-01 at 15:10 +0000, Daniel P. Berrangé wrote:
> On Mon, Dec 01, 2025 at 12:50:24PM +0000, Chalios, Babis wrote:
> > Latest specification of VMClock[1] adds support for VM generation counter
> > and notifications. VM generation counter is similar to disruption_marker
> > but it only changes when the guest has been loaded from a snapshot, not
> > on live migration. Its purpose is to notify the guest about snapshot
> > events and let it perform actions such as recreating UUIDs, resetting
> > network connections, reseeding entropy, etc.
> > 
> > Moreover, the spec now describes a notification that the device can send
> > after updating the seq counter to a new even number.
> > 
> > I have already sent the Linux changes to the mailing list here:
> > https://lore.kernel.org/lkml/20251127103159.19816-1-bchalios@amazon.es/T/#u
> > 
> > [1] https://david.woodhou.se/VMClock.pdf
> 
> Should that spec document the expected behaviour of guests when a hypervisor
> advertizes both vmclock and vmgenid devices ?
> 
> QEMU supports both, and to avoid assumptions about whether a guest supports
> the newer vmclock, I could expect mgmt apps to expose both these QEMU
> devices.
> 
> IIUC, your intent is that 'vmclock' obsoletes the need for 'vmgenid', so
> should the spec say that explicitly, and suggest that guest kernels ignore
> the vmgenid if both  are present, to avoid the same kind of actions being
> triggered twice ?

The intent is not to obsolete vmgenid, but we do signal when a clock
disruption is associated with a snapshot (and thus with a vmgenid
change), and the conditions for bumping that counter (which is what you
were reviewing) will be the same as the conditions for when to
regenerate a new vmgenid UUID.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]