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

[Babis Chalios <bchalios@amazon.es>]

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