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

[Cornelia Huck <cohuck@redhat.com>]

On Mon, Dec 01 2025, David Woodhouse <dwmw2@infradead.org> 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. 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 ;)