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/[email protected]/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.
smime.p7s
Description: S/MIME cryptographic signature
