hw/acpi/core.c | 8 +++++- hw/acpi/vmclock.c | 28 +++++++++++++++++++- include/hw/acpi/acpi_dev_interface.h | 1 + include/standard-headers/linux/vmclock-abi.h | 20 ++++++++++++++ 4 files changed, 55 insertions(+), 2 deletions(-)
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 Babis Chalios (4): acpi: fix acpi_send_gpe_event() to handle more events hw/acpi: add new fields in VMClock ABI hw/acpi: add VM generation counter field to VMClock hw/acpi: add ACPI notification to VMClock device hw/acpi/core.c | 8 +++++- hw/acpi/vmclock.c | 28 +++++++++++++++++++- include/hw/acpi/acpi_dev_interface.h | 1 + include/standard-headers/linux/vmclock-abi.h | 20 ++++++++++++++ 4 files changed, 55 insertions(+), 2 deletions(-) -- 2.34.1
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 ? 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 :|
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 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 :| >
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.
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 Babis Chalios (4): acpi: fix acpi_send_gpe_event() to handle more events hw/acpi: add new fields in VMClock ABI hw/acpi: add VM generation counter field to VMClock hw/acpi: add ACPI notification to VMClock device hw/acpi/core.c | 8 +++++- hw/acpi/vmclock.c | 28 +++++++++++++++++++- include/hw/acpi/acpi_dev_interface.h | 1 + include/standard-headers/linux/vmclock-abi.h | 20 ++++++++++++++ 4 files changed, 55 insertions(+), 2 deletions(-) -- 2.34.1
© 2016 - 2025 Red Hat, Inc.