From: Babis Chalios <bchalios@amazon.es>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "mst@redhat.com" <mst@redhat.com>,
"imammedo@redhat.com" <imammedo@redhat.com>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"dwmw2@infradead.org" <dwmw2@infradead.org>, "Graf (AWS),
Alexander" <graf@amazon.de>,
"mzxreary@0pointer.de" <mzxreary@0pointer.de>
Subject: Re: [RFC PATCH 0/4] vmclock: add support for VM generation counter and notifications
Date: Mon, 1 Dec 2025 16:46:49 +0100 [thread overview]
Message-ID: <5dcae34ba9eb8e505de01039657f33dc87dffeeb.camel@amazon.es> (raw)
In-Reply-To: <aS2v1nTakVbWYbht@redhat.com>
On Mon, 2025-12-01 at 15:10 +0000, Daniel P. Berrangé wrote:
> On Mon, Dec 01, 2025 at 12:50:24PM +0000, Chalios, Babis wrote:
> > Latest specification of VMClock[1] adds support for VM generation
> > counter
> > and notifications. VM generation counter is similar to
> > disruption_marker
> > but it only changes when the guest has been loaded from a snapshot,
> > not
> > on live migration. Its purpose is to notify the guest about
> > snapshot
> > events and let it perform actions such as recreating UUIDs,
> > resetting
> > network connections, reseeding entropy, etc.
> >
> > Moreover, the spec now describes a notification that the device can
> > send
> > after updating the seq counter to a new even number.
> >
> > I have already sent the Linux changes to the mailing list here:
> > https://lore.kernel.org/lkml/20251127103159.19816-1-bchalios@amazon.es/T/#u
> >
> > [1] https://david.woodhou.se/VMClock.pdf
>
> Should that spec document the expected behaviour of guests when a
> hypervisor
> advertizes both vmclock and vmgenid devices ?
>
> QEMU supports both, and to avoid assumptions about whether a guest
> supports
> the newer vmclock, I could expect mgmt apps to expose both these QEMU
> devices.
>
> IIUC, your intent is that 'vmclock' obsoletes the need for 'vmgenid',
> so
> should the spec say that explicitly, and suggest that guest kernels
> ignore
> the vmgenid if both are present, to avoid the same kind of actions
> being
> triggered twice ?
>
>
The two devices are completely orthogonal. VMGenID (as implemented in
Linux) is used to let the guest kernel know that it needs to reseed its
internal PRNG. VMClock, instead, notifies guest user-space about the
snapshot loading event. It is not about the kernel and it is not
restricted to restricted to reseeding entropy pools.
Cheers,
Babis
> With regards,
> Daniel
> --
> > : https://berrange.com -o-
> > https://www.flickr.com/photos/dberrange :|
> > : https://libvirt.org -o-
> > https://fstop138.berrange.com :|
> > : https://entangle-photo.org -o-
> > https://www.instagram.com/dberrange :|
>
prev parent reply other threads:[~2025-12-01 15:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-01 12:50 [RFC PATCH 0/4] vmclock: add support for VM generation counter and notifications Chalios, Babis
2025-12-01 12:50 ` Chalios, Babis
2025-12-01 12:52 ` Babis Chalios
2025-12-01 12:50 ` [RFC PATCH 1/4] acpi: fix acpi_send_gpe_event() to handle more events Chalios, Babis
2025-12-01 12:50 ` [RFC PATCH 2/4] hw/acpi: add new fields in VMClock ABI Chalios, Babis
2025-12-01 13:04 ` Cornelia Huck
2025-12-01 13:11 ` Babis Chalios
2025-12-01 13:36 ` Cornelia Huck
2025-12-01 13:24 ` David Woodhouse
2025-12-01 13:38 ` Cornelia Huck
2025-12-01 14:27 ` David Woodhouse
2025-12-01 15:05 ` Babis Chalios
2025-12-01 15:21 ` David Woodhouse
2025-12-01 15:10 ` Cornelia Huck
2025-12-01 12:51 ` [RFC PATCH 3/4] hw/acpi: add VM generation counter field to VMClock Chalios, Babis
2025-12-01 14:12 ` Daniel P. Berrangé
2025-12-01 14:29 ` David Woodhouse
2025-12-01 14:41 ` Daniel P. Berrangé
2025-12-01 15:01 ` Babis Chalios
2025-12-01 15:28 ` David Woodhouse
2025-12-01 12:51 ` [RFC PATCH 4/4] hw/acpi: add ACPI notification to VMClock device Chalios, Babis
2025-12-01 15:10 ` [RFC PATCH 0/4] vmclock: add support for VM generation counter and notifications Daniel P. Berrangé
2025-12-01 15:23 ` David Woodhouse
2025-12-01 15:46 ` Babis Chalios [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5dcae34ba9eb8e505de01039657f33dc87dffeeb.camel@amazon.es \
--to=bchalios@amazon.es \
--cc=berrange@redhat.com \
--cc=cohuck@redhat.com \
--cc=dwmw2@infradead.org \
--cc=graf@amazon.de \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=mzxreary@0pointer.de \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).