On Mon, Dec 01 2025, David Woodhouse <[email protected]> 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. 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 ;)
