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 two devices are completely orthogonal. VMGenID (as implemented in Linux) is used to let the guest kernel know that it needs to reseed its internal PRNG. VMClock, instead, notifies guest user-space about the snapshot loading event. It is not about the kernel and it is not restricted to restricted to reseeding entropy pools. 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 :| >
