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 <[email protected]> wrote: > > > > > On Mon, 2025-12-01 at 14:04 +0100, Cornelia Huck wrote: > > > > On Mon, Dec 01 2025, "Chalios, Babis" <[email protected]> > > > > 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 <[email protected]> > > > > > --- > > > > > 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
