From: Paolo Abeni <pabeni@redhat.com>
To: "Chalios, Babis" <bchalios@amazon.es>,
"robh@kernel.org" <robh@kernel.org>,
"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"richardcochran@gmail.com" <richardcochran@gmail.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"kuba@kernel.org" <kuba@kernel.org>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Graf (AWS), Alexander" <graf@amazon.de>,
"mzxreary@0pointer.de" <mzxreary@0pointer.de>,
"Cali, Marco" <xmarcalx@amazon.co.uk>
Subject: Re: [PATCH v4 0/7] ptp: vmclock: Add VM generation counter and ACPI notification
Date: Sun, 28 Dec 2025 15:42:32 +0100 [thread overview]
Message-ID: <5fe241dd-ae17-4cfe-80f7-e7ea80f8b781@redhat.com> (raw)
In-Reply-To: <20251218142408.8395-1-bchalios@amazon.es>
On 12/18/25 3:24 PM, Chalios, Babis wrote:
> Similarly to live migration, starting a VM from some serialized state
> (aka snapshot) is an event which calls for adjusting guest clocks, hence
> a hypervisor should increase the disruption_marker before resuming the
> VM vCPUs, letting the guest know.
>
> However, loading a snapshot, is slightly different than live migration,
> especially since we can start multiple VMs from the same serialized
> state. Apart from adjusting clocks, the guest needs to take additional
> action during such events, e.g. recreate UUIDs, reset network
> adapters/connections, reseed entropy pools, etc. These actions are not
> necessary during live migration. This calls for a differentiation
> between the two triggering events.
>
> We differentiate between the two events via an extra field in the
> vmclock_abi, called vm_generation_counter. Whereas hypervisors should
> increase the disruption marker in both cases, they should only increase
> vm_generation_counter when a snapshot is loaded in a VM (not during live
> migration).
>
> Additionally, we attach an ACPI notification to VMClock. Implementing
> the notification is optional for the device. VMClock device will declare
> that it implements the notification by setting
> VMCLOCK_FLAG_NOTIFICATION_PRESENT bit in vmclock_abi flags. Hypervisors
> that implement the notification must send an ACPI notification every
> time seq_count changes to an even number. The driver will propagate
> these notifications to userspace via the poll() interface.
There are a few formal things to adjust (reverse christmas tree order in
variable declaration, empty changelog in patch 6/7, prefer #if
IS_ENABLED() over #ifdef). Moreover:
## Form letter - net-next-closed
The net-next tree is closed for new drivers, features, code refactoring
and optimizations due to the merge window and the winter break. We are
currently accepting bug fixes only.
Please repost when net-next reopens after Jan 2nd.
RFC patches sent for review only are obviously welcome at any time.
next prev parent reply other threads:[~2025-12-28 14:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-18 14:24 Chalios, Babis
2025-12-18 14:24 ` [PATCH v4 1/7] ptp: vmclock: add vm generation counter Chalios, Babis
2025-12-18 14:24 ` [PATCH v4 2/7] ptp: vmclock: support device notifications Chalios, Babis
2025-12-18 14:24 ` [PATCH v4 3/7] dt-bindings: ptp: Add amazon,vmclock Chalios, Babis
2025-12-18 14:24 ` [PATCH v4 4/7] ptp: ptp_vmclock: Add device tree support Chalios, Babis
2025-12-18 14:25 ` [PATCH v4 5/7] ptp: ptp_vmclock: add 'VMCLOCK' to ACPI device match Chalios, Babis
2025-12-18 14:25 ` [PATCH v4 6/7] ptp: ptp_vmclock: remove dependency on CONFIG_ACPI Chalios, Babis
2025-12-18 14:25 ` [PATCH v4 7/7] ptp: ptp_vmclock: return TAI not UTC Chalios, Babis
2025-12-28 14:42 ` Paolo Abeni [this message]
2026-01-05 14:13 ` [PATCH v4 0/7] ptp: vmclock: Add VM generation counter and ACPI notification David Woodhouse
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=5fe241dd-ae17-4cfe-80f7-e7ea80f8b781@redhat.com \
--to=pabeni@redhat.com \
--cc=andrew+netdev@lunn.ch \
--cc=bchalios@amazon.es \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=edumazet@google.com \
--cc=graf@amazon.de \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mzxreary@0pointer.de \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
--cc=robh@kernel.org \
--cc=xmarcalx@amazon.co.uk \
/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
all inboxes | Powered by JetHome®