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

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

[Chalios, Babis]

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

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

[Chalios, Babis]

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

[RFC PATCH 1/4] acpi: fix acpi_send_gpe_event() to handle more events

[Chalios, Babis]

acpi_send_gpe_events() sends events encoded in the AcpiEventStatusBits
enum. The maximum bit used so far in the latter was 128, hence a single
byte (ACPIGPE.sts[0]) is currently enough to hold the set bits.

When we add an extra one, we will need a second byte to encode the state
and casting from AcpiEventStatusBits to uint8_t will silently ignore the
higher bits.

Fix this, by taking into account the length value inside ACPIGPE.

Signed-off-by: Babis Chalios <bchalios@amazon.es>
---
 hw/acpi/core.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index ff16582803..48694eca54 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -730,7 +730,13 @@ uint32_t acpi_gpe_ioport_readb(ACPIREGS *ar, uint32_t addr)
 void acpi_send_gpe_event(ACPIREGS *ar, qemu_irq irq,
                          AcpiEventStatusBits status)
 {
-    ar->gpe.sts[0] |= status;
+    int i;
+
+    for (i = 0; i < ar->gpe.len; i++) {
+        ar->gpe.sts[i] |= (status & 0xff);
+        status >>= 8;
+    }
+
     acpi_update_sci(ar, irq);
 }
 
-- 
2.34.1

[RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI

[Chalios, Babis]

VMClock now supports a vm_generation_counter field in the struct it
exposes to userspace. The field signals a disruption that happened due
to a guest loaded from a snapshot.

Moreover, VMClock now optionally supports device notifications when the
seq_count changes to a new even value.

Signed-off-by: Babis Chalios <bchalios@amazon.es>
---
 include/standard-headers/linux/vmclock-abi.h | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/include/standard-headers/linux/vmclock-abi.h b/include/standard-headers/linux/vmclock-abi.h
index 15b0316cb4..fe824badc0 100644
--- a/include/standard-headers/linux/vmclock-abi.h
+++ b/include/standard-headers/linux/vmclock-abi.h
@@ -115,6 +115,17 @@ struct vmclock_abi {
 	 * bit again after the update, using the about-to-be-valid fields.
 	 */
 #define VMCLOCK_FLAG_TIME_MONOTONIC		(1 << 7)
+	/*
+	 * If the VM_GEN_COUNTER_PRESENT flag is set, the hypervisor will
+	 * bump the vm_generation_counter field every time the guest is
+	 * loaded from some save state (restored from a snapshot).
+	 */
+#define VMCLOCK_FLAG_VM_GEN_COUNTER_PRESENT     (1 << 8)
+	/*
+	 * If the NOTIFICATION_PRESENT flag is set, the hypervisor will send
+	 * a notification every time it updates seq_count to a new even number.
+	 */
+#define VMCLOCK_FLAG_NOTIFICATION_PRESENT       (1 << 9)
 
 	uint8_t pad[2];
 	uint8_t clock_status;
@@ -177,6 +188,15 @@ struct vmclock_abi {
 	uint64_t time_frac_sec;		/* Units of 1/2^64 of a second */
 	uint64_t time_esterror_nanosec;
 	uint64_t time_maxerror_nanosec;
+
+	/*
+	 * This field changes to another non-repeating value when the guest
+	 * has been loaded from a snapshot. In addition to handling a
+	 * disruption in time (which will also be signalled through the
+	 * disruption_marker field), a guest may wish to discard UUIDs,
+	 * reset network connections, reseed entropy, etc.
+	 */
+	uint64_t vm_generation_counter;
 };
 
 #endif /*  __VMCLOCK_ABI_H__ */
-- 
2.34.1

[RFC PATCH 3/4] hw/acpi: add VM generation counter field to VMClock

[Chalios, Babis]

The final published version of the VMClock specification adds support
for an extra vm_generation_counter field which allows hypervisors to
differentiate between live migration and snapshot loading events. During
the latter, apart from adjusting clocks, guests might want to take
further actions such as resetting network devices, updating UUIDs,
reseeding entropy pools, etc.

VM generation counter itself is stored in the guest memory region and
exposed to guest userspace, so we don't need to serialize it within
vmstate_vmclock as well.

Signed-off-by: Babis Chalios <bchalios@amazon.es>
---
 hw/acpi/vmclock.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/hw/acpi/vmclock.c b/hw/acpi/vmclock.c
index c582c0c1f8..47cbba4496 100644
--- a/hw/acpi/vmclock.c
+++ b/hw/acpi/vmclock.c
@@ -20,6 +20,7 @@
 #include "hw/qdev-properties.h"
 #include "hw/qdev-properties-system.h"
 #include "migration/vmstate.h"
+#include "migration/misc.h"
 #include "system/reset.h"
 
 #include "standard-headers/linux/vmclock-abi.h"
@@ -64,6 +65,7 @@ void vmclock_build_acpi(VmclockState *vms, GArray *table_data,
 static void vmclock_update_guest(VmclockState *vms)
 {
     uint64_t disruption_marker;
+    uint64_t vm_generation_counter;
     uint32_t seq_count;
 
     if (!vms->clk) {
@@ -79,6 +81,16 @@ static void vmclock_update_guest(VmclockState *vms)
     disruption_marker++;
     vms->clk->disruption_marker = cpu_to_le64(disruption_marker);
 
+    /*
+     * We only increase the vm_generation_counter when loading from a snapshot,
+     * not during live migration
+     */
+    if (!migration_is_running()) {
+        vm_generation_counter = le64_to_cpu(vms->clk->vm_generation_counter);
+        vm_generation_counter++;
+        vms->clk->vm_generation_counter = cpu_to_le64(vm_generation_counter);
+    }
+
     /* These barriers pair with read barriers in the guest */
     smp_wmb();
     vms->clk->seq_count = cpu_to_le32(seq_count + 1);
@@ -144,6 +156,7 @@ static void vmclock_realize(DeviceState *dev, Error **errp)
     vms->clk->magic = cpu_to_le32(VMCLOCK_MAGIC);
     vms->clk->size = cpu_to_le16(VMCLOCK_SIZE);
     vms->clk->version = cpu_to_le16(1);
+    vms->clk->flags = cpu_to_le64(VMCLOCK_FLAG_VM_GEN_COUNTER_PRESENT);
 
     /* These are all zero and thus default, but be explicit */
     vms->clk->clock_status = VMCLOCK_STATUS_UNKNOWN;
-- 
2.34.1

[RFC PATCH 4/4] hw/acpi: add ACPI notification to VMClock device

[Chalios, Babis]

Extend VMClock device to send an ACPI notification every time the
seqcount changes to a new even value. Use GPE E08 event, which now
becomes part of the guest ABI.

Signed-off-by: Babis Chalios <bchalios@amazon.es>
---
 hw/acpi/vmclock.c                    | 17 +++++++++++++++--
 include/hw/acpi/acpi_dev_interface.h |  1 +
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/acpi/vmclock.c b/hw/acpi/vmclock.c
index 47cbba4496..f6f242cb66 100644
--- a/hw/acpi/vmclock.c
+++ b/hw/acpi/vmclock.c
@@ -28,7 +28,7 @@
 void vmclock_build_acpi(VmclockState *vms, GArray *table_data,
                         BIOSLinker *linker, const char *oem_id)
 {
-    Aml *ssdt, *dev, *scope, *crs;
+    Aml *ssdt, *dev, *scope, *crs, *method;
     AcpiTable table = { .sig = "SSDT", .rev = 1,
                         .oem_id = oem_id, .oem_table_id = "VMCLOCK" };
 
@@ -57,6 +57,11 @@ void vmclock_build_acpi(VmclockState *vms, GArray *table_data,
     aml_append(scope, dev);
     aml_append(ssdt, scope);
 
+    /* Attach an ACPI notify */
+    method = aml_method("\\_GPE._E08", 0, AML_NOTSERIALIZED);
+    aml_append(method, aml_notify(aml_name("\\_SB.VCLK"), aml_int(0x80)));
+    aml_append(ssdt, method);
+
     g_array_append_vals(table_data, ssdt->buf->data, ssdt->buf->len);
     acpi_table_end(linker, &table);
     free_aml_allocator();
@@ -67,6 +72,10 @@ static void vmclock_update_guest(VmclockState *vms)
     uint64_t disruption_marker;
     uint64_t vm_generation_counter;
     uint32_t seq_count;
+    Object *obj = object_resolve_path_type("", TYPE_ACPI_DEVICE_IF, NULL);
+    if (!obj) {
+        return;
+    }
 
     if (!vms->clk) {
         return;
@@ -94,6 +103,9 @@ static void vmclock_update_guest(VmclockState *vms)
     /* These barriers pair with read barriers in the guest */
     smp_wmb();
     vms->clk->seq_count = cpu_to_le32(seq_count + 1);
+
+    /* Send _GPE.E08 event */
+    acpi_send_event(DEVICE(obj), ACPI_VMCLOCK_CHANGE_STATUS);
 }
 
 /*
@@ -156,7 +168,8 @@ static void vmclock_realize(DeviceState *dev, Error **errp)
     vms->clk->magic = cpu_to_le32(VMCLOCK_MAGIC);
     vms->clk->size = cpu_to_le16(VMCLOCK_SIZE);
     vms->clk->version = cpu_to_le16(1);
-    vms->clk->flags = cpu_to_le64(VMCLOCK_FLAG_VM_GEN_COUNTER_PRESENT);
+    vms->clk->flags = cpu_to_le64(VMCLOCK_FLAG_VM_GEN_COUNTER_PRESENT |
+                                  VMCLOCK_FLAG_NOTIFICATION_PRESENT);
 
     /* These are all zero and thus default, but be explicit */
     vms->clk->clock_status = VMCLOCK_STATUS_UNKNOWN;
diff --git a/include/hw/acpi/acpi_dev_interface.h b/include/hw/acpi/acpi_dev_interface.h
index 8294f8f0cc..f51f6065f9 100644
--- a/include/hw/acpi/acpi_dev_interface.h
+++ b/include/hw/acpi/acpi_dev_interface.h
@@ -14,6 +14,7 @@ typedef enum {
     ACPI_VMGENID_CHANGE_STATUS = 32,
     ACPI_POWER_DOWN_STATUS = 64,
     ACPI_GENERIC_ERROR = 128,
+    ACPI_VMCLOCK_CHANGE_STATUS = 256,
 } AcpiEventStatusBits;
 
 #define TYPE_ACPI_DEVICE_IF "acpi-device-interface"
-- 
2.34.1

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

[Babis Chalios]

[-- Attachment #1: Type: text/html, Size: 2052 bytes --]

Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI

[Cornelia Huck]

On Mon, Dec 01 2025, "Chalios, Babis" <bchalios@amazon.es> wrote:

> VMClock now supports a vm_generation_counter field in the struct it
> exposes to userspace. The field signals a disruption that happened due
> to a guest loaded from a snapshot.
>
> Moreover, VMClock now optionally supports device notifications when the
> seq_count changes to a new even value.
>
> Signed-off-by: Babis Chalios <bchalios@amazon.es>
> ---
>  include/standard-headers/linux/vmclock-abi.h | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)

Please either do a full linux-headers update against a specific Linux
kernel version, or mark this as a placeholder patch if the code is not
yet merged.

Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI

[Babis Chalios]

[-- Attachment #1: Type: text/html, Size: 1595 bytes --]

Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI

[David Woodhouse]

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

On Mon, 2025-12-01 at 14:04 +0100, Cornelia Huck wrote:
> On Mon, Dec 01 2025, "Chalios, Babis" <bchalios@amazon.es> wrote:
> 
> > VMClock now supports a vm_generation_counter field in the struct it
> > exposes to userspace. The field signals a disruption that happened due
> > to a guest loaded from a snapshot.
> > 
> > Moreover, VMClock now optionally supports device notifications when the
> > seq_count changes to a new even value.
> > 
> > Signed-off-by: Babis Chalios <bchalios@amazon.es>
> > ---
> >  include/standard-headers/linux/vmclock-abi.h | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> 
> Please either do a full linux-headers update against a specific Linux
> kernel version, or mark this as a placeholder patch if the code is not
> yet merged.

The Linux patches are being posted simultaneously, so they'll be in
Linux 6.20 (7.0?) at the earliest. We'll want to ingest the update
before then.

The intent is not for the Linux source to be the canonical definition
of the data structure; we *are* working on publishing the spec, and
Babis referenced the current draft. It isn't in the form of C source
code though, so I suspect it makes sense to keep including the Linux
header?

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

Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI

[Cornelia Huck]

On Mon, Dec 01 2025, Babis Chalios <bchalios@amazon.es> wrote:

> On 12/1/25 14:04, Cornelia Huck wrote: 
>
>  
> On Mon, Dec 01 2025, "Chalios, Babis" <bchalios@amazon.es> wrote:
>
>  VMClock now supports a vm_generation_counter field in the struct it
> exposes to userspace. The field signals a disruption that happened due
> to a guest loaded from a snapshot.
>
> Moreover, VMClock now optionally supports device notifications when the
> seq_count changes to a new even value.
>
> Signed-off-by: Babis Chalios <bchalios@amazon.es>
> ---
>  include/standard-headers/linux/vmclock-abi.h | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
>
> Please either do a full linux-headers update against a specific Linux
> kernel version, or mark this as a placeholder patch if the code is not
> yet merged.
>
> Indeed, that's a placeholder. What's the process to mark this as a placeholder?

I think a simple "DO NOT MERGE" in the subject will do :)

Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI

[Cornelia Huck]

On Mon, Dec 01 2025, David Woodhouse <dwmw2@infradead.org> wrote:

> On Mon, 2025-12-01 at 14:04 +0100, Cornelia Huck wrote:
>> On Mon, Dec 01 2025, "Chalios, Babis" <bchalios@amazon.es> wrote:
>> 
>> > VMClock now supports a vm_generation_counter field in the struct it
>> > exposes to userspace. The field signals a disruption that happened due
>> > to a guest loaded from a snapshot.
>> > 
>> > Moreover, VMClock now optionally supports device notifications when the
>> > seq_count changes to a new even value.
>> > 
>> > Signed-off-by: Babis Chalios <bchalios@amazon.es>
>> > ---
>> >  include/standard-headers/linux/vmclock-abi.h | 20 ++++++++++++++++++++
>> >  1 file changed, 20 insertions(+)
>> 
>> Please either do a full linux-headers update against a specific Linux
>> kernel version, or mark this as a placeholder patch if the code is not
>> yet merged.
>
> The Linux patches are being posted simultaneously, so they'll be in
> Linux 6.20 (7.0?) at the earliest. We'll want to ingest the update
> before then.
>
> The intent is not for the Linux source to be the canonical definition
> of the data structure; we *are* working on publishing the spec, and
> Babis referenced the current draft. It isn't in the form of C source
> code though, so I suspect it makes sense to keep including the Linux
> header?

Oh, including the Linux header sounds fine; but as long as the code has
not yet been merged there, this needs to be marked as not yet ready to
merge on the QEMU side. (And it needs to be updated by a full headers
update when merged.)

Re: [RFC PATCH 3/4] hw/acpi: add VM generation counter field to VMClock

[Daniel P. Berrangé]

On Mon, Dec 01, 2025 at 12:51:10PM +0000, Chalios, Babis wrote:
> The final published version of the VMClock specification adds support
> for an extra vm_generation_counter field which allows hypervisors to
> differentiate between live migration and snapshot loading events. During
> the latter, apart from adjusting clocks, guests might want to take
> further actions such as resetting network devices, updating UUIDs,
> reseeding entropy pools, etc.
> 
> VM generation counter itself is stored in the guest memory region and
> exposed to guest userspace, so we don't need to serialize it within
> vmstate_vmclock as well.
> 
> Signed-off-by: Babis Chalios <bchalios@amazon.es>
> ---
>  hw/acpi/vmclock.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/hw/acpi/vmclock.c b/hw/acpi/vmclock.c
> index c582c0c1f8..47cbba4496 100644
> --- a/hw/acpi/vmclock.c
> +++ b/hw/acpi/vmclock.c
> @@ -20,6 +20,7 @@
>  #include "hw/qdev-properties.h"
>  #include "hw/qdev-properties-system.h"
>  #include "migration/vmstate.h"
> +#include "migration/misc.h"
>  #include "system/reset.h"
>  
>  #include "standard-headers/linux/vmclock-abi.h"
> @@ -64,6 +65,7 @@ void vmclock_build_acpi(VmclockState *vms, GArray *table_data,
>  static void vmclock_update_guest(VmclockState *vms)
>  {
>      uint64_t disruption_marker;
> +    uint64_t vm_generation_counter;
>      uint32_t seq_count;
>  
>      if (!vms->clk) {
> @@ -79,6 +81,16 @@ static void vmclock_update_guest(VmclockState *vms)
>      disruption_marker++;
>      vms->clk->disruption_marker = cpu_to_le64(disruption_marker);
>  
> +    /*
> +     * We only increase the vm_generation_counter when loading from a snapshot,
> +     * not during live migration
> +     */
> +    if (!migration_is_running()) {
> +        vm_generation_counter = le64_to_cpu(vms->clk->vm_generation_counter);
> +        vm_generation_counter++;
> +        vms->clk->vm_generation_counter = cpu_to_le64(vm_generation_counter);
> +    }

I don't believe this conditional works. Run it with

  $ qemu-system-x86_64 -monitor stdio -device vmclock
  (qemu) migrate tcp:localhost:9000

and

  $ qemu-system-x86_64 -monitor stdio -device vmclock -incoming tcp:localhost:9000


and the vm_generation_counter always gets updated on every migrate
operation.

'migration_is_running()' is always returning 'false' when this callback
is triggered on the target.

Even if it were to return 'true' as this code expects, this would not
allow to distinguish between snapshots and live migration. The QEMU
"migrate" / "migrate-incoming" commands are used by mgmt apps to
implement snapshots. From QEMU's POV, live migration and snapshots
are indistiguishable operations, both using the same functionaility.

eg
  $ qemu-system-x86_64 -monitor stdio -device vmclock
  (qemu) migrate file:snapshot.img

and

  $ qemu-system-x86_64 -monitor stdio -device vmclock -incoming file:snapshot.img


and we can't check the QEMU migration target being "file:" and mgmt
apps can use the "fd:" protocol to pass in a pre-opened target which can
be a socket or pipe or file.

Only the mgmt app knows if this is for a snapshot or a live migration or
something else.

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 :|

Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI

[David Woodhouse]

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

On Mon, 2025-12-01 at 14:38 +0100, Cornelia Huck wrote:
> On Mon, Dec 01 2025, David Woodhouse <dwmw2@infradead.org> wrote:
> 
> > On Mon, 2025-12-01 at 14:04 +0100, Cornelia Huck wrote:
> > > On Mon, Dec 01 2025, "Chalios, Babis" <bchalios@amazon.es> wrote:
> > > 
> > > > VMClock now supports a vm_generation_counter field in the struct it
> > > > exposes to userspace. The field signals a disruption that happened due
> > > > to a guest loaded from a snapshot.
> > > > 
> > > > Moreover, VMClock now optionally supports device notifications when the
> > > > seq_count changes to a new even value.
> > > > 
> > > > Signed-off-by: Babis Chalios <bchalios@amazon.es>
> > > > ---
> > > >  include/standard-headers/linux/vmclock-abi.h | 20 ++++++++++++++++++++
> > > >  1 file changed, 20 insertions(+)
> > > 
> > > Please either do a full linux-headers update against a specific Linux
> > > kernel version, or mark this as a placeholder patch if the code is not
> > > yet merged.
> > 
> > The Linux patches are being posted simultaneously, so they'll be in
> > Linux 6.20 (7.0?) at the earliest. We'll want to ingest the update
> > before then.
> > 
> > The intent is not for the Linux source to be the canonical definition
> > of the data structure; we *are* working on publishing the spec, and
> > Babis referenced the current draft. It isn't in the form of C source
> > code though, so I suspect it makes sense to keep including the Linux
> > header?
> 
> Oh, including the Linux header sounds fine; but as long as the code has
> not yet been merged there, this needs to be marked as not yet ready to
> merge on the QEMU side. (And it needs to be updated by a full headers
> update when merged.)

That's exactly what we *don't* want, and why we say that the canonical
definition of this structure is the actual specification. There's no
need for QEMU to only ever follow Linux.

In that case, probably best *not* to use the Linux header and instead
to build our own specifically for QEMU based on the specification. It
can be almost byte-for-byte identical, but just needs to live elsewhere
rather than in <standard-headers/linux>



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

Re: [RFC PATCH 3/4] hw/acpi: add VM generation counter field to VMClock

[David Woodhouse]

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

On Mon, 2025-12-01 at 14:12 +0000, Daniel P. Berrangé wrote:
> From QEMU's POV, live migration and snapshots
> are indistiguishable operations, both using the same functionaility.
> 
> eg
>   $ qemu-system-x86_64 -monitor stdio -device vmclock
>   (qemu) migrate file:snapshot.img
> 
> and
> 
>   $ qemu-system-x86_64 -monitor stdio -device vmclock -incoming file:snapshot.img
> 
> 
> and we can't check the QEMU migration target being "file:" and mgmt
> apps can use the "fd:" protocol to pass in a pre-opened target which can
> be a socket or pipe or file.

What triggers the vmgenid to actually get updated for a snapshot?
That's the condition we're after, isn't it?

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

Re: [RFC PATCH 3/4] hw/acpi: add VM generation counter field to VMClock

[Daniel P. Berrangé]

On Mon, Dec 01, 2025 at 02:29:57PM +0000, David Woodhouse wrote:
> On Mon, 2025-12-01 at 14:12 +0000, Daniel P. Berrangé wrote:
> > From QEMU's POV, live migration and snapshots
> > are indistiguishable operations, both using the same functionaility.
> > 
> > eg
> >   $ qemu-system-x86_64 -monitor stdio -device vmclock
> >   (qemu) migrate file:snapshot.img
> > 
> > and
> > 
> >   $ qemu-system-x86_64 -monitor stdio -device vmclock -incoming file:snapshot.img
> > 
> > 
> > and we can't check the QEMU migration target being "file:" and mgmt
> > apps can use the "fd:" protocol to pass in a pre-opened target which can
> > be a socket or pipe or file.
> 
> What triggers the vmgenid to actually get updated for a snapshot?
> That's the condition we're after, isn't it?

I don't quiet understand the sequences, but libvirt is involved in setting
guid=nnnn as an arg to -device vmgenid when it spawns QEMU. This means
libvirt has control over when it is changed or not.

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 :|

Re: [RFC PATCH 3/4] hw/acpi: add VM generation counter field to VMClock

[Babis Chalios]

On Mon, 2025-12-01 at 14:41 +0000, Daniel P. Berrangé wrote:
> On Mon, Dec 01, 2025 at 02:29:57PM +0000, David Woodhouse wrote:
> > On Mon, 2025-12-01 at 14:12 +0000, Daniel P. Berrangé wrote:
> > > From QEMU's POV, live migration and snapshots
> > > are indistiguishable operations, both using the same
> > > functionaility.
> > > 
> > > eg
> > >   $ qemu-system-x86_64 -monitor stdio -device vmclock
> > >   (qemu) migrate file:snapshot.img
> > > 
> > > and
> > > 
> > >   $ qemu-system-x86_64 -monitor stdio -device vmclock -incoming
> > > file:snapshot.img
> > > 
> > > 
> > > and we can't check the QEMU migration target being "file:" and
> > > mgmt
> > > apps can use the "fd:" protocol to pass in a pre-opened target
> > > which can
> > > be a socket or pipe or file.
> > 
> > What triggers the vmgenid to actually get updated for a snapshot?
> > That's the condition we're after, isn't it?
> 
> I don't quiet understand the sequences, but libvirt is involved in
> setting
> guid=nnnn as an arg to -device vmgenid when it spawns QEMU. This
> means
> libvirt has control over when it is changed or not.
> 

That's a shame :(

Maybe we could do the same as VMGenID then. Make vm_generation_counter
something that the user can set when creating the device (same as
VMGenID's GUID). WDYT David?

Cheers,
Babis

Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI

[Babis Chalios]

On Mon, 2025-12-01 at 14:27 +0000, David Woodhouse wrote:
> On Mon, 2025-12-01 at 14:38 +0100, Cornelia Huck wrote:
> > On Mon, Dec 01 2025, David Woodhouse <dwmw2@infradead.org> wrote:
> > 
> > > On Mon, 2025-12-01 at 14:04 +0100, Cornelia Huck wrote:
> > > > On Mon, Dec 01 2025, "Chalios, Babis" <bchalios@amazon.es>
> > > > wrote:
> > > > 
> > > > > VMClock now supports a vm_generation_counter field in the
> > > > > struct it
> > > > > exposes to userspace. The field signals a disruption that
> > > > > happened due
> > > > > to a guest loaded from a snapshot.
> > > > > 
> > > > > Moreover, VMClock now optionally supports device
> > > > > notifications when the
> > > > > seq_count changes to a new even value.
> > > > > 
> > > > > Signed-off-by: Babis Chalios <bchalios@amazon.es>
> > > > > ---
> > > > >  include/standard-headers/linux/vmclock-abi.h | 20
> > > > > ++++++++++++++++++++
> > > > >  1 file changed, 20 insertions(+)
> > > > 
> > > > Please either do a full linux-headers update against a specific
> > > > Linux
> > > > kernel version, or mark this as a placeholder patch if the code
> > > > is not
> > > > yet merged.
> > > 
> > > The Linux patches are being posted simultaneously, so they'll be
> > > in
> > > Linux 6.20 (7.0?) at the earliest. We'll want to ingest the
> > > update
> > > before then.
> > > 
> > > The intent is not for the Linux source to be the canonical
> > > definition
> > > of the data structure; we *are* working on publishing the spec,
> > > and
> > > Babis referenced the current draft. It isn't in the form of C
> > > source
> > > code though, so I suspect it makes sense to keep including the
> > > Linux
> > > header?
> > 
> > Oh, including the Linux header sounds fine; but as long as the code
> > has
> > not yet been merged there, this needs to be marked as not yet ready
> > to
> > merge on the QEMU side. (And it needs to be updated by a full
> > headers
> > update when merged.)
> 
> That's exactly what we *don't* want, and why we say that the
> canonical
> definition of this structure is the actual specification. There's no
> need for QEMU to only ever follow Linux.
> 
> In that case, probably best *not* to use the Linux header and instead
> to build our own specifically for QEMU based on the specification.

I can do that for v1!

> It can be almost byte-for-byte identical

Why "almost", though?

Cheers,
Babis

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

[Daniel P. Berrangé]

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 :|

Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI

[Cornelia Huck]

On Mon, Dec 01 2025, David Woodhouse <dwmw2@infradead.org> wrote:

> On Mon, 2025-12-01 at 14:38 +0100, Cornelia Huck wrote:
>> On Mon, Dec 01 2025, David Woodhouse <dwmw2@infradead.org> wrote:
>> 
>> > On Mon, 2025-12-01 at 14:04 +0100, Cornelia Huck wrote:
>> > > On Mon, Dec 01 2025, "Chalios, Babis" <bchalios@amazon.es> wrote:
>> > > 
>> > > > VMClock now supports a vm_generation_counter field in the struct it
>> > > > exposes to userspace. The field signals a disruption that happened due
>> > > > to a guest loaded from a snapshot.
>> > > > 
>> > > > Moreover, VMClock now optionally supports device notifications when the
>> > > > seq_count changes to a new even value.
>> > > > 
>> > > > Signed-off-by: Babis Chalios <bchalios@amazon.es>
>> > > > ---
>> > > >  include/standard-headers/linux/vmclock-abi.h | 20 ++++++++++++++++++++
>> > > >  1 file changed, 20 insertions(+)
>> > > 
>> > > Please either do a full linux-headers update against a specific Linux
>> > > kernel version, or mark this as a placeholder patch if the code is not
>> > > yet merged.
>> > 
>> > The Linux patches are being posted simultaneously, so they'll be in
>> > Linux 6.20 (7.0?) at the earliest. We'll want to ingest the update
>> > before then.
>> > 
>> > The intent is not for the Linux source to be the canonical definition
>> > of the data structure; we *are* working on publishing the spec, and
>> > Babis referenced the current draft. It isn't in the form of C source
>> > code though, so I suspect it makes sense to keep including the Linux
>> > header?
>> 
>> Oh, including the Linux header sounds fine; but as long as the code has
>> not yet been merged there, this needs to be marked as not yet ready to
>> merge on the QEMU side. (And it needs to be updated by a full headers
>> update when merged.)
>
> That's exactly what we *don't* want, and why we say that the canonical
> definition of this structure is the actual specification. There's no
> need for QEMU to only ever follow Linux.
>
> In that case, probably best *not* to use the Linux header and instead
> to build our own specifically for QEMU based on the specification. It
> can be almost byte-for-byte identical, but just needs to live elsewhere
> rather than in <standard-headers/linux>

Yes, if you want to disentangle this, the header needs to go somewhere
else in QEMU. This is only my "someone changed something in
standard-headers without a headers sync" triggering ;)

Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI

[David Woodhouse]

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

On Mon, 2025-12-01 at 16:05 +0100, Babis Chalios wrote:
> On Mon, 2025-12-01 at 14:27 +0000, David Woodhouse wrote:
> > That's exactly what we *don't* want, and why we say that the canonical
> > definition of this structure is the actual specification. There's no
> > need for QEMU to only ever follow Linux.
> > 
> > In that case, probably best *not* to use the Linux header and instead
> > to build our own specifically for QEMU based on the specification.
> 
> I can do that for v1!
> 
> > It can be almost byte-for-byte identical
> 
> Why "almost", though?

Well, the SPDX tag probably changes at least? And don't we change the
Linux __leXX types to proper C99 types as we import?

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

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

[David Woodhouse]

[-- 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 --]

Re: [RFC PATCH 3/4] hw/acpi: add VM generation counter field to VMClock

[David Woodhouse]

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

On Mon, 2025-12-01 at 16:01 +0100, Babis Chalios wrote:
> 
> That's a shame :(
> 
> Maybe we could do the same as VMGenID then. Make vm_generation_counter
> something that the user can set when creating the device (same as
> VMGenID's GUID). WDYT David?

Hm, can we store the current vmgenid in the vmlcock serialised state
and then bump the counter if it *changes*? Arguably we shouldn't be
advertising the VMCLOCK_FLAG_VM_GEN_COUNTER_PRESENT flag if there is no
vmgenid anyway, so we should *already* be looking at least for its
presence?

That way, when the external tooling launches the new QEMU for the
snapshot with the new vmgenid, we will spot it and bump the counter
accordingly?

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

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

[Babis Chalios]

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 :|
>