Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI
On Mon, 2025-12-01 at 16:05 +0100, Babis Chalios wrote: > On Mon, 2025-12-01 at 14:27 +, 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? smime.p7s Description: S/MIME cryptographic signature
Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI
On Mon, Dec 01 2025, David Woodhouse wrote: > On Mon, 2025-12-01 at 14:38 +0100, Cornelia Huck wrote: >> On Mon, Dec 01 2025, David Woodhouse wrote: >> >> > On Mon, 2025-12-01 at 14:04 +0100, Cornelia Huck wrote: >> > > On Mon, Dec 01 2025, "Chalios, Babis" 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 >> > > > --- >> > > > 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 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
On Mon, 2025-12-01 at 14:27 +, David Woodhouse wrote: > On Mon, 2025-12-01 at 14:38 +0100, Cornelia Huck wrote: > > On Mon, Dec 01 2025, David Woodhouse wrote: > > > > > On Mon, 2025-12-01 at 14:04 +0100, Cornelia Huck wrote: > > > > On Mon, Dec 01 2025, "Chalios, Babis" > > > > 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 > > > > > --- > > > > > 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 2/4] hw/acpi: add new fields in VMClock ABI
On Mon, 2025-12-01 at 14:38 +0100, Cornelia Huck wrote: > On Mon, Dec 01 2025, David Woodhouse wrote: > > > On Mon, 2025-12-01 at 14:04 +0100, Cornelia Huck wrote: > > > On Mon, Dec 01 2025, "Chalios, Babis" 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 > > > > --- > > > > 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 smime.p7s Description: S/MIME cryptographic signature
Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI
On Mon, Dec 01 2025, David Woodhouse wrote: > On Mon, 2025-12-01 at 14:04 +0100, Cornelia Huck wrote: >> On Mon, Dec 01 2025, "Chalios, Babis" 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 >> > --- >> > 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 2/4] hw/acpi: add new fields in VMClock ABI
On Mon, Dec 01 2025, Babis Chalios wrote: > On 12/1/25 14:04, Cornelia Huck wrote: > > > On Mon, Dec 01 2025, "Chalios, Babis" 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 > --- > 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
On Mon, 2025-12-01 at 14:04 +0100, Cornelia Huck wrote: > On Mon, Dec 01 2025, "Chalios, Babis" 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 > > --- > > 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? smime.p7s Description: S/MIME cryptographic signature
Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI
On 12/1/25 14:04, Cornelia Huck wrote: On Mon, Dec 01 2025, "Chalios, Babis" 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 --- 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? Cheers, Babis
Re: [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI
On Mon, Dec 01 2025, "Chalios, Babis" 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 > --- > 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.
[RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI
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
---
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
