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>


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to