* Re: [PATCH RFC 3/4] printk: nbcon: move printk_delay to console emiting code
From: Petr Mladek @ 2026-06-08 15:25 UTC (permalink / raw)
To: Andrew Murray
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Clark Williams, Randy Dunlap,
Linus Torvalds, linux-doc, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <20260601-deprecate_boot_delay-v1-3-c34c187142a6@thegoodpenguin.co.uk>
On Mon 2026-06-01 00:17:39, Andrew Murray wrote:
> The printk_delay and boot_delay features are helpful for debugging
> as kernel output can be slowed down during boot allowing messages to
> be seen before scrolling off the screen, or to correlate timing between
> some physical event and console output.
>
> However, since the introduction of nbcon and the legacy printer thread
> for PREEMPT_RT kernels, printk records are now emited to the console
> asynchronously to the caller of printk. Thus, any printk delay added by
> boot_delay/printk_delay continues to slow down the calling process but
> may not have any impact to the rate in which records are emited to the
> console.
>
> Let's address this by moving the printk delay from the calling code
> to the console emiting code instead. Whilst this ensures that delays
> are still observed (especially for slower consoles), it doesn't improve
> the use-case of using boot_delay/printk_delay to correlate timings
> between physical events and console output.
>
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
The declaration is needed just inside kernel/printk/ directory.
It should better be done via kernel/printk/internal.h
> @@ -209,6 +209,7 @@ extern bool nbcon_device_try_acquire(struct console *con);
> extern void nbcon_device_release(struct console *con);
> void nbcon_atomic_flush_unsafe(void);
> bool pr_flush(int timeout_ms, bool reset_on_progress);
> +void printk_delay(bool use_atomic);
> #else
> static inline __printf(1, 0)
> int vprintk(const char *s, va_list args)
> @@ -326,6 +327,9 @@ static inline bool pr_flush(int timeout_ms, bool reset_on_progress)
> {
> return true;
> }
> +static inline void printk_delay(bool use_atomic)
> +{
> +}
>
> #endif
>
> diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> index d7044a7a214bdd4537a5e20d876d99bc3ffe8b3a..a507a2fed5bf4366e24330f763b842a698ecf6f7 100644
> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -1267,11 +1267,16 @@ static int nbcon_kthread_func(void *__console)
>
> con_flags = console_srcu_read_flags(con);
>
> + wctxt.len = 0;
> +
> if (console_is_usable(con, con_flags, false))
> backlog = nbcon_emit_one(&wctxt, false);
>
> console_srcu_read_unlock(cookie);
>
> + if (backlog && wctxt.len > 0)
Heh, this is tricky. It might probably work but it is not guarantted
by design.
The "backlog" name is a bit misleading. The value is basically
wctxt.ctxt.backlog. The real meaning is that printk_get_next_message()
was able to read a message. It means that there _was_ a backlog.
But it is not clear whether there are still pending messages or not.
Also it is not clear that whether the message was pushed to the
console or not. It might have been supressed in which case
(wctxt.len == 0). But it might also be emitted only partially
when a higher priority context took over the console context
ownership.
I would prefer to explicitely set some flag when
nbcon_emit_next_record() really called con->write*().
See below.
> + printk_delay(false);
> +
> cond_resched();
>
> } while (backlog);
> @@ -1525,6 +1530,8 @@ bool nbcon_legacy_emit_next_record(struct console *con, bool *handover,
> }
>
> progress = nbcon_emit_one(&wctxt, use_atomic);
> + if (progress && wctxt.len > 0)
Same here.
> + printk_delay(use_atomic);
>
> if (use_atomic) {
> start_critical_timings();
> @@ -1584,6 +1591,8 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> if (!nbcon_context_try_acquire(ctxt, false))
> return -EPERM;
>
> + wctxt.len = 0;
> +
> /*
> * nbcon_emit_next_record() returns false when
> * the console was handed over or taken over.
> @@ -1595,7 +1604,9 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> nbcon_context_release(ctxt);
> }
>
> - if (!ctxt->backlog) {
> + if (ctxt->backlog && wctxt.len > 0) {
> + printk_delay(true);
> + } else {
This changes the semantic. The original code call this when
no message was read. The new code would call this path also
when the output was suppressed. It would probably work.
But still.
> /* Are there reserved but not yet finalized records? */
> if (nbcon_seq_read(con) < stop_seq)
> err = -ENOENT;
As mentioned above, I would add a flag which would be set when
con->write*() was called.
It modifies the type of unsafe_takeover in struct nbcon_write_context.
But it actually makes it more compatible with struct nbcon_state.
My proposal (on top of this patch):
diff --git a/include/linux/console.h b/include/linux/console.h
index 5520e4477ad7..5a86942e55ef 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -290,6 +290,7 @@ struct nbcon_context {
* @outbuf: Pointer to the text buffer for output
* @len: Length to write
* @unsafe_takeover: If a hostile takeover in an unsafe state has occurred
+ * @emitted: The write context tried to emit the message. Might be incomplete.
* @cpu: CPU on which the message was generated
* @pid: PID of the task that generated the message
* @comm: Name of the task that generated the message
@@ -298,7 +299,8 @@ struct nbcon_write_context {
struct nbcon_context __private ctxt;
char *outbuf;
unsigned int len;
- bool unsafe_takeover;
+ unsigned char unsafe_takeover : 1;
+ unsigned char emitted : 1
#ifdef CONFIG_PRINTK_EXECUTION_CTX
int cpu;
pid_t pid;
diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
index a507a2fed5bf..060534becefc 100644
--- a/kernel/printk/nbcon.c
+++ b/kernel/printk/nbcon.c
@@ -1069,6 +1069,9 @@ static bool nbcon_emit_next_record(struct nbcon_write_context *wctxt, bool use_a
else
con->write_thread(con, wctxt);
+ /* Tried to emit something. Might be incomplete. */
+ wctxt.emitted = 1;
+
if (!wctxt->outbuf) {
/*
* Ownership was lost and reacquired by the driver. Handle it
@@ -1267,14 +1270,14 @@ static int nbcon_kthread_func(void *__console)
con_flags = console_srcu_read_flags(con);
- wctxt.len = 0;
+ wctxt.emitted = 0;
if (console_is_usable(con, con_flags, false))
backlog = nbcon_emit_one(&wctxt, false);
console_srcu_read_unlock(cookie);
- if (backlog && wctxt.len > 0)
+ if (wctxt.emitted)
printk_delay(false);
cond_resched();
@@ -1530,7 +1533,7 @@ bool nbcon_legacy_emit_next_record(struct console *con, bool *handover,
}
progress = nbcon_emit_one(&wctxt, use_atomic);
- if (progress && wctxt.len > 0)
+ if (wctxt.emitted)
printk_delay(use_atomic);
if (use_atomic) {
@@ -1591,7 +1594,7 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
if (!nbcon_context_try_acquire(ctxt, false))
return -EPERM;
- wctxt.len = 0;
+ wctxt.emitted = 0;
/*
* nbcon_emit_next_record() returns false when
@@ -1604,9 +1607,10 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
nbcon_context_release(ctxt);
}
- if (ctxt->backlog && wctxt.len > 0) {
+ if (wctxt.emitted)
printk_delay(true);
- } else {
+
+ if (!ctxt->backlog) {
/* Are there reserved but not yet finalized records? */
if (nbcon_seq_read(con) < stop_seq)
err = -ENOENT;
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH iwl-next v8 08/15] idpf: refactor idpf to use libie_pci APIs
From: Loktionov, Aleksandr @ 2026-06-08 15:16 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Zaremba, Larysa, Fijalkowski, Maciej, Tantilov, Emil S,
Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Salin, Samuel
In-Reply-To: <20260608144127.2751230-9-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Monday, June 8, 2026 4:41 PM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Salin, Samuel
> <samuel.salin@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v8 08/15] idpf: refactor
> idpf to use libie_pci APIs
>
> From: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
>
> Use libie_pci init and MMIO APIs where possible, struct idpf_hw cannot
> be deleted for now as it also houses control queues that will be
> refactored later. Use libie_cp header for libie_ctlq_ctx that contains
> mmio info from the start in order to not increase the diff later.
>
> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
> Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> Tested-by: Samuel Salin <Samuel.salin@intel.com>
> Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> ---
> drivers/net/ethernet/intel/idpf/Kconfig | 1 +
> drivers/net/ethernet/intel/idpf/idpf.h | 70 +-------
> .../net/ethernet/intel/idpf/idpf_controlq.c | 26 ++-
> .../net/ethernet/intel/idpf/idpf_controlq.h | 2 -
> drivers/net/ethernet/intel/idpf/idpf_dev.c | 61 ++++---
> drivers/net/ethernet/intel/idpf/idpf_idc.c | 38 ++--
> drivers/net/ethernet/intel/idpf/idpf_lib.c | 7 +-
> drivers/net/ethernet/intel/idpf/idpf_main.c | 114 ++++++------
> drivers/net/ethernet/intel/idpf/idpf_vf_dev.c | 57 +++---
> .../net/ethernet/intel/idpf/idpf_virtchnl.c | 169 +++++++++--------
> -
> .../ethernet/intel/idpf/idpf_virtchnl_ptp.c | 58 +++---
> 11 files changed, 288 insertions(+), 315 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/Kconfig
> b/drivers/net/ethernet/intel/idpf/Kconfig
> index adab2154125b..586df3a4afe9 100644
> --- a/drivers/net/ethernet/intel/idpf/Kconfig
> +++ b/drivers/net/ethernet/intel/idpf/Kconfig
> @@ -6,6 +6,7 @@ config IDPF
> depends on PCI_MSI
> depends on PTP_1588_CLOCK_OPTIONAL
> select DIMLIB
...
> +56,14 @@ static void idpf_ctlq_reg_init(struct idpf_adapter *adapter,
> */
> static void idpf_mb_intr_reg_init(struct idpf_adapter *adapter) {
> + struct libie_mmio_info *mmio = &adapter->ctlq_ctx.mmio_info;
> struct idpf_intr_reg *intr = &adapter->mb_vector.intr_reg;
> u32 dyn_ctl = le32_to_cpu(adapter->caps.mailbox_dyn_ctl);
>
> - intr->dyn_ctl = idpf_get_reg_addr(adapter, dyn_ctl);
> + intr->dyn_ctl = libie_pci_get_mmio_addr(mmio, dyn_ctl);
Probable NULL dereference: libie_pci_get_mmio_addr(mmio, dyn_ctl) can return NULL.
It looks like no checks were made.
> intr->dyn_ctl_intena_m = PF_GLINT_DYN_CTL_INTENA_M;
> intr->dyn_ctl_itridx_m = PF_GLINT_DYN_CTL_ITR_INDX_M;
...
>
> return 0;
> }
> --
> 2.47.0
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v8 07/15] idpf: remove unused code for getting RSS info from device
From: Loktionov, Aleksandr @ 2026-06-08 15:10 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Zaremba, Larysa, Fijalkowski, Maciej, Tantilov, Emil S,
Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260608144127.2751230-8-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Monday, June 8, 2026 4:41 PM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-next v8 07/15] idpf: remove
> unused code for getting RSS info from device
>
> idpf_send_get_set_rss_lut_msg() and idpf_send_get_set_rss_key_msg() do
> not handle the get=true path properly. Response validation is
> insufficient, memcpy size is wrong, LE-to-CPU conversion is missing.
> Fortunately, those functions are never used with get=true. Given how
> broken this dead code is, it is unlikely to be useful in the future.
>
> Rename idpf_send_get_set_rss_lut_msg() to idpf_send_set_rss_lut_msg(),
> idpf_send_get_set_rss_key_msg() to idpf_send_set_rss_key_msg(), remove
> the get parameter and remove all get=true cases from the function.
>
> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> ---
> drivers/net/ethernet/intel/idpf/idpf_txrx.c | 4 +-
> .../net/ethernet/intel/idpf/idpf_virtchnl.c | 107 +++--------------
> -
> .../net/ethernet/intel/idpf/idpf_virtchnl.h | 10 +-
> 3 files changed, 22 insertions(+), 99 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> index f6b3b15364ff..d744db0efd3f 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> @@ -4679,11 +4679,11 @@ int idpf_config_rss(struct idpf_vport *vport,
> struct idpf_rss_data *rss_data)
> u32 vport_id = vport->vport_id;
> int err;
>
...
> vport_id);
> void idpf_vc_xn_shutdown(struct idpf_vc_xn_manager *vcxn_mngr); int
> idpf_idc_rdma_vc_send_sync(struct iidc_rdma_core_dev_info *cdev_info,
> u8 *send_msg, u16 msg_size,
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v8 06/15] idpf: remove 'vport_params_reqd' field
From: Loktionov, Aleksandr @ 2026-06-08 15:09 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Zaremba, Larysa, Fijalkowski, Maciej, Tantilov, Emil S,
Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Salin, Samuel
In-Reply-To: <20260608144127.2751230-7-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Monday, June 8, 2026 4:41 PM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Salin, Samuel
> <samuel.salin@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v8 06/15] idpf: remove
> 'vport_params_reqd' field
>
> From: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
>
> While sending a create vport message to the device control plane, a
> create vport virtchnl message is prepared with all the required info
> to initialize the vport. This info is stored in the adapter struct but
> never used thereafter. So, remove the said field.
>
> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
> Tested-by: Samuel Salin <Samuel.salin@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> ---
> drivers/net/ethernet/intel/idpf/idpf.h | 2 --
> drivers/net/ethernet/intel/idpf/idpf_lib.c | 2 --
> .../net/ethernet/intel/idpf/idpf_virtchnl.c | 30 +++++++-----------
> -
> 3 files changed, 10 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf.h
> b/drivers/net/ethernet/intel/idpf/idpf.h
> index 984944bab28b..c5e47e79a641 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf.h
> +++ b/drivers/net/ethernet/intel/idpf/idpf.h
> @@ -638,7 +638,6 @@ struct idpf_vc_xn_manager;
> * @avail_queues: Device given queue limits
> * @vports: Array to store vports created by the driver
> * @netdevs: Associated Vport netdevs
...
>
> adapter->vport_ids = kcalloc(num_max_vports, sizeof(u32),
> GFP_KERNEL);
> if (!adapter->vport_ids)
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v8 03/15] libeth: allow to create fill queues without NAPI
From: Loktionov, Aleksandr @ 2026-06-08 15:09 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Zaremba, Larysa, Fijalkowski, Maciej, Tantilov, Emil S,
Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, R, Bharath, Salin, Samuel
In-Reply-To: <20260608144127.2751230-4-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Monday, June 8, 2026 4:41 PM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; R, Bharath
> <bharath.r@intel.com>; Salin, Samuel <samuel.salin@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v8 03/15] libeth: allow to
> create fill queues without NAPI
>
> From: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
>
> Control queues can utilize libeth_rx fill queues, despite working
> outside of NAPI context. The only problem is standard fill queues
> requiring NAPI that provides them with the device pointer.
>
> Introduce a way to provide the device directly without using NAPI.
>
> Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> Tested-by: Bharath R <bharath.r@intel.com>
> Tested-by: Samuel Salin <Samuel.salin@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> ---
> drivers/net/ethernet/intel/libeth/rx.c | 12 ++++++++----
> include/net/libeth/rx.h | 4 +++-
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/libeth/rx.c
> b/drivers/net/ethernet/intel/libeth/rx.c
> index 62521a1f4ec9..0c1a565a1b3a 100644
> --- a/drivers/net/ethernet/intel/libeth/rx.c
> +++ b/drivers/net/ethernet/intel/libeth/rx.c
> @@ -145,25 +145,29 @@ static bool libeth_rx_page_pool_params_zc(struct
> libeth_fq *fq,
> /**
> * libeth_rx_fq_create - create a PP with the default libeth settings
> * @fq: buffer queue struct to fill
> - * @napi: &napi_struct covering this PP (no usage outside its poll
> loops)
> + * @napi_dev: &napi_struct for NAPI (data) queues, &device for others
> *
> * Return: %0 on success, -%errno on failure.
> */
> -int libeth_rx_fq_create(struct libeth_fq *fq, struct napi_struct
> *napi)
> +int libeth_rx_fq_create(struct libeth_fq *fq, void *napi_dev)
> {
> + struct napi_struct *napi = fq->no_napi ? NULL : napi_dev;
> struct page_pool_params pp = {
> .flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV,
> .order = LIBETH_RX_PAGE_ORDER,
> .pool_size = fq->count,
> .nid = fq->nid,
> - .dev = napi->dev->dev.parent,
> - .netdev = napi->dev,
> + .dev = napi ? napi->dev->dev.parent : napi_dev,
> + .netdev = napi ? napi->dev : NULL,
> .napi = napi,
> };
> struct libeth_fqe *fqes;
> struct page_pool *pool;
> int ret;
>
> + if (!pp.netdev && fq->type == LIBETH_FQE_MTU)
> + return -EINVAL;
> +
> pp.dma_dir = fq->xdp ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE;
>
> if (!fq->hsplit)
> diff --git a/include/net/libeth/rx.h b/include/net/libeth/rx.h index
> 5d991404845e..0e736846c5e8 100644
> --- a/include/net/libeth/rx.h
> +++ b/include/net/libeth/rx.h
> @@ -69,6 +69,7 @@ enum libeth_fqe_type {
> * @type: type of the buffers this queue has
> * @hsplit: flag whether header split is enabled
> * @xdp: flag indicating whether XDP is enabled
> + * @no_napi: the queue is not a data queue and does not have NAPI
> * @buf_len: HW-writeable length per each buffer
> * @nid: ID of the closest NUMA node with memory
> */
> @@ -85,12 +86,13 @@ struct libeth_fq {
> enum libeth_fqe_type type:2;
> bool hsplit:1;
> bool xdp:1;
> + bool no_napi:1;
>
> u32 buf_len;
> int nid;
> };
>
> -int libeth_rx_fq_create(struct libeth_fq *fq, struct napi_struct
> *napi);
> +int libeth_rx_fq_create(struct libeth_fq *fq, void *napi_dev);
> void libeth_rx_fq_destroy(struct libeth_fq *fq);
>
> /**
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v8 01/15] virtchnl: move virtchnl and virtchnl2 headers to 'include/linux/net/intel'
From: Loktionov, Aleksandr @ 2026-06-08 15:08 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Zaremba, Larysa, Fijalkowski, Maciej, Tantilov, Emil S,
Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Salin, Samuel
In-Reply-To: <20260608144127.2751230-2-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Monday, June 8, 2026 4:41 PM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Salin, Samuel
> <samuel.salin@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v8 01/15] virtchnl: move
> virtchnl and virtchnl2 headers to 'include/linux/net/intel'
>
> From: Victor Raj <victor.raj@intel.com>
>
> virtchnl2 headers will be used by both idpf and ixd drivers, so they
> have to be moved to an include directory. On top of that, it would be
> useful to place all iavf headers together with other intel networking
> headers.
>
> Move abovementioned intel header files into 'include/linux/net/intel'.
>
> Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> Signed-off-by: Victor Raj <victor.raj@intel.com>
> Tested-by: Samuel Salin <Samuel.salin@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> ---
> MAINTAINERS | 1 -
> drivers/net/ethernet/intel/i40e/i40e.h | 2 +-
> drivers/net/ethernet/intel/i40e/i40e_common.c | 2 +-
> drivers/net/ethernet/intel/i40e/i40e_prototype.h | 2 +-
> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h | 2 +-
> drivers/net/ethernet/intel/iavf/iavf.h | 2 +-
> drivers/net/ethernet/intel/iavf/iavf_common.c | 2 +-
> drivers/net/ethernet/intel/iavf/iavf_prototype.h | 3 ++-
> drivers/net/ethernet/intel/iavf/iavf_types.h | 4 +--
> -
> drivers/net/ethernet/intel/ice/ice.h | 2 +-
> drivers/net/ethernet/intel/ice/ice_common.h | 2 +-
> drivers/net/ethernet/intel/ice/ice_vf_lib.h | 2 +-
> drivers/net/ethernet/intel/ice/virt/virtchnl.h | 2 +-
> drivers/net/ethernet/intel/idpf/idpf.h | 2 +-
> drivers/net/ethernet/intel/idpf/idpf_txrx.h | 2 +-
> drivers/net/ethernet/intel/idpf/idpf_virtchnl.h | 2 +-
> include/linux/{avf => net/intel}/virtchnl.h | 0
> .../intel/idpf => include/linux/net/intel}/virtchnl2.h | 0
> .../idpf => include/linux/net/intel}/virtchnl2_lan_desc.h | 0
> 19 files changed, 16 insertions(+), 18 deletions(-) rename
> include/linux/{avf => net/intel}/virtchnl.h (100%) rename
> {drivers/net/ethernet/intel/idpf =>
> include/linux/net/intel}/virtchnl2.h (100%) rename
> {drivers/net/ethernet/intel/idpf =>
> include/linux/net/intel}/virtchnl2_lan_desc.h (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index eb8cdcc76324..952f09b40711 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12917,7 +12917,6 @@ T: git
> git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git
> F: Documentation/networking/device_drivers/ethernet/intel/
> F: drivers/net/ethernet/intel/
> F: drivers/net/ethernet/intel/*/
...
>
> #define IDPF_VC_XN_DEFAULT_TIMEOUT_MSEC (60 * 1000)
> #define IDPF_VC_XN_IDX_M GENMASK(7, 0)
> diff --git a/include/linux/avf/virtchnl.h
> b/include/linux/net/intel/virtchnl.h
> similarity index 100%
> rename from include/linux/avf/virtchnl.h rename to
> include/linux/net/intel/virtchnl.h
> diff --git a/drivers/net/ethernet/intel/idpf/virtchnl2.h
> b/include/linux/net/intel/virtchnl2.h
> similarity index 100%
> rename from drivers/net/ethernet/intel/idpf/virtchnl2.h
> rename to include/linux/net/intel/virtchnl2.h
> diff --git a/drivers/net/ethernet/intel/idpf/virtchnl2_lan_desc.h
> b/include/linux/net/intel/virtchnl2_lan_desc.h
> similarity index 100%
> rename from drivers/net/ethernet/intel/idpf/virtchnl2_lan_desc.h
> rename to include/linux/net/intel/virtchnl2_lan_desc.h
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [RFC PATCH v1 00/13] exec: add spawn templates for repeated executable startup
From: Jann Horn @ 2026-06-08 15:02 UTC (permalink / raw)
To: Mateusz Guzik, Christian Brauner
Cc: Li Chen, Kees Cook, Alexander Viro, linux-fsdevel, linux-api,
linux-kernel, linux-mm, linux-arch, linux-doc, linux-kselftest,
x86, Arnd Bergmann, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Jan Kara,
Jonathan Corbet, Shuah Khan
In-Reply-To: <vealb52tv5suireenkke4lul2l3wbnaul2rp3ea545ly5wa5ty@yk3aksvp7skt>
On Thu, May 28, 2026 at 2:55 PM Mateusz Guzik <mjguzik@gmail.com> wrote:
> This problem is dear to my heart and I have been pondering it on and off
> for some time now. The entire fork + exec idiom is terrible and needs to
> be retired.
It seems to me like vfork+exec is a decent UAPI building block, on
which you can build nice-looking userspace APIs, though I agree that
this is not an ideal direct interface for application code.
> Additionally there is a known problem where transiently copied file
> descriptors on fork + exec cause a headache in multithreaded programs
> doing something like this in parallel. I only did cursory reading, it
> seems your patchset keeps the same problem in place.
I think we almost have UAPI that would let you avoid this issue?
You can use clone() with CLONE_FILES, then unshare the FD table with
close_range(3, UINT_MAX, CLOSE_RANGE_UNSHARE). That is not currently
implemented to be atomic with stuff that happens on other threads, but
if we changed that, and it doesn't provide a good way to carry some
FDs across, but it feels to me like this could be fixed with a variant
of close_range() that removes O_CLOEXEC FDs except ones listed in an
array.
> There are numerous impactful ways to speed up execs both in terms of
> single-threaded cost and their multicore scalability, most of which
> would be immediately usable by all programs without an opt-in. imo these
> needs to be exhausted before something like a "template" can be
> considered.
(I think probably a large part of this would be stuff that happens in
userspace, like dynamic linking.)
> Per the above, the primary win would stem from *NOT* messing with mm.
As you write below, I think we have that with CLONE_MM? The C function
vfork() is kind of a terrible API because of its returns-twice
behavior, but I think if process cloning with CLONE_VM|CLONE_VFORK was
wrapped by libc in a way similar to clone() (with the child executing
a separate handler function), or if it was used in the implementation
of some higher-level process-spawning API, it would be a perfectly
fine API?
Or am I misunderstanding what you mean by "messing with mm"?
> As in, whatever the interface, it needs to create an "empty" target
> process (for lack of a better term).
>
> In terms of userspace-visible APIs, a clean solution escapes me.
I think we already have relatively good API for this - you can use
clone() to create something that initially shares almost all the state
that a thread would, and then incrementally unshare resources and go
through execve().
^ permalink raw reply
* Re: [PATCH mm-unstable v19 11/14] mm/khugepaged: Introduce mTHP collapse support
From: David Hildenbrand (Arm) @ 2026-06-08 14:56 UTC (permalink / raw)
To: Lance Yang, npache
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
liam, ljs, mathieu.desnoyers, matthew.brost, mhiramat, mhocko,
peterx, pfalcato, rakie.kim, raquini, rdunlap, richard.weiyang,
rientjes, rostedt, rppt, ryan.roberts, shivankg, sunnanyong,
surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <20260606102800.26940-1-lance.yang@linux.dev>
On 6/6/26 12:28, Lance Yang wrote:
>
> On Fri, Jun 05, 2026 at 10:14:18AM -0600, Nico Pache wrote:
>> Enable khugepaged to collapse to mTHP orders. This patch implements the
>> main scanning logic using a bitmap to track occupied pages and the
>> algorithm to find optimal collapse sizes.
>>
>> Previous to this patch, PMD collapse had 3 main phases, a light weight
>> scanning phase (mmap_read_lock) that determines a potential PMD
>> collapse, an alloc phase (mmap unlocked), then finally heavier collapse
>> phase (mmap_write_lock).
>>
>> To enabled mTHP collapse we make the following changes:
>>
>> During PMD scan phase, track occupied pages in a bitmap. When mTHP
>> orders are enabled, we remove the restriction of max_ptes_none during the
>> scan phase to avoid missing potential mTHP collapse candidates. Once we
>> have scanned the full PMD range and updated the bitmap to track occupied
>> pages, we use the bitmap to find the optimal mTHP size.
>>
>> Implement mthp_collapse() to walk forward through the bitmap and
>> determine the best eligible order for each naturally-aligned region. The
>> algorithm starts at the beginning of the PMD range and, for each offset,
>> tries the highest order that fits the alignment. If the number of
>> occupied PTEs in that region satisfies the max_ptes_none threshold for
>> that order, a collapse is attempted. On failure, the order is
>> decremented and the same offset is retried at the next smaller size. Once
>> the smallest enabled order is exhausted (or a collapse succeeds), the
>> offset advances past the region just processed, and the next attempt
>> starts at the highest order permitted by the new offset's natural
>> alignment.
>>
>> The algorithm works as follows:
>> 1) set offset=0 and order=HPAGE_PMD_ORDER
>> 2) if the order is not enabled, go to step (5)
>> 3) count occupied PTEs in the (offset, order) range using
>> bitmap_weight_from()
>> 4) if the count satisfies the max_ptes_none threshold, attempt
>> collapse; on success, advance to step (6)
>> 5) if a smaller enabled order exists, decrement order and retry
>> from step (2) at the same offset
>> 6) advance offset past the current region and compute the next
>> order from the new offset's natural alignment via __ffs(offset),
>> capped at HPAGE_PMD_ORDER
>> 7) repeat from step (2) until the full PMD range is covered
>>
>> mTHP collapses reject regions containing swapped out or shared pages.
>> This is because adding new entries can lead to new none pages, and these
>> may lead to constant promotion into a higher order mTHP. A similar
>> issue can occur with "max_ptes_none > HPAGE_PMD_NR/2" due to a collapse
>> introducing at least 2x the number of pages, and on a future scan will
>> satisfy the promotion condition once again. This issue is prevented via
>> the collapse_max_ptes_none() function which imposes the max_ptes_none
>> restrictions above.
>>
>> We currently only support mTHP collapse for max_ptes_none values of 0
>> and HPAGE_PMD_NR - 1. resulting in the following behavior:
>>
>> - max_ptes_none=0: Never introduce new empty pages during collapse
>> - max_ptes_none=HPAGE_PMD_NR-1: Always try collapse to the highest
>> available mTHP order
>>
>> Any other max_ptes_none value will emit a warning and default mTHP
>> collapse to max_ptes_none=0. There should be no behavior change for PMD
>> collapse.
>>
>> Once we determine what mTHP sizes fits best in that PMD range a collapse
>> is attempted. A minimum collapse order of 2 is used as this is the lowest
>> order supported by anon memory as defined by THP_ORDERS_ALL_ANON.
>>
>> Currently madv_collapse is not supported and will only attempt PMD
>> collapse.
>>
>> We can also remove the check for is_khugepaged inside the PMD scan as
>> the collapse_max_ptes_none() function handles this logic now.
>>
>> Signed-off-by: Nico Pache <npache@redhat.com>
>> ---
>> mm/khugepaged.c | 146 +++++++++++++++++++++++++++++++++++++++++++++---
>> 1 file changed, 138 insertions(+), 8 deletions(-)
>>
>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>> index ec886a031952..430047316f43 100644
>> --- a/mm/khugepaged.c
>> +++ b/mm/khugepaged.c
>> @@ -99,6 +99,8 @@ static DEFINE_READ_MOSTLY_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
>>
>> static struct kmem_cache *mm_slot_cache __ro_after_init;
>>
>> +#define KHUGEPAGED_MIN_MTHP_ORDER 2
>> +
>> struct collapse_control {
>> bool is_khugepaged;
>>
>> @@ -110,6 +112,9 @@ struct collapse_control {
>>
>> /* nodemask for allocation fallback */
>> nodemask_t alloc_nmask;
>> +
>> + /* Each bit represents a single occupied (!none/zero) page. */
>> + DECLARE_BITMAP(mthp_present_ptes, MAX_PTRS_PER_PTE);
>> };
>>
>> /**
>> @@ -1440,20 +1445,130 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s
>> return result;
>> }
>>
>> +/* Return the highest naturally aligned order that fits at @offset within a PMD. */
>> +static unsigned int max_order_from_offset(unsigned int offset)
>> +{
>> + if (offset == 0)
>> + return HPAGE_PMD_ORDER;
>> +
>> + return min_t(unsigned int, __ffs(offset), HPAGE_PMD_ORDER);
>> +}
>> +
>> +/*
>> + * mthp_collapse() consumes the bitmap that is generated during
>> + * collapse_scan_pmd() to determine what regions and mTHP orders fit best.
>> + *
>> + * Each bit in cc->mthp_present_ptes represents a single occupied (!none/zero)
>> + * page. We start at the PMD order and check if it is eligible for collapse;
>> + * if not, we check the left and right halves of the PTE page table we are
>> + * examining at a lower order.
>> + *
>> + * For each of these, we determine how many PTE entries are occupied in the
>> + * range of PTE entries we propose to collapse, then we compare this to a
>> + * threshold number of PTE entries which would need to be occupied for a
>> + * collapse to be permitted at that order (accounting for max_ptes_none).
>> + *
>> + * If a collapse is permitted, we attempt to collapse the PTE range into a
>> + * mTHP.
>> + */
>> +static enum scan_result mthp_collapse(struct mm_struct *mm,
>> + unsigned long address, int referenced, int unmapped,
>> + struct collapse_control *cc, unsigned long enabled_orders)
>> +{
>> + unsigned int nr_occupied_ptes, nr_ptes, max_ptes_none;
>> + enum scan_result last_result = SCAN_FAIL;
>> + int collapsed = 0;
>> + bool alloc_failed = false;
>> + unsigned long collapse_address;
>> + unsigned int offset = 0;
>> + unsigned int order = HPAGE_PMD_ORDER;
>> +
>> + while (offset < HPAGE_PMD_NR) {
>> + nr_ptes = 1UL << order;
>> +
>> + if (!test_bit(order, &enabled_orders))
>> + goto next_order;
>> +
>> + max_ptes_none = collapse_max_ptes_none(cc, NULL, order);
>> + nr_occupied_ptes = bitmap_weight_from(cc->mthp_present_ptes, offset,
>> + offset + nr_ptes);
>> +
>> + if (nr_occupied_ptes >= nr_ptes - max_ptes_none) {
>
> Looks broken for swap PTEs in PMD collapse ...
>
> collapse_scan_pmd() allows them up to max_ptes_swap and record them in
> unmapped, but they don't get a bit in mthp_present_ptes. And then
> mthp_collapse() does the check above:
Right. I assumed this is implicitly handled by the optimization in collapse_scan_pmd:
if (enabled_orders != BIT(HPAGE_PMD_ORDER))
max_ptes_none = KHUGEPAGED_MAX_PTES_LIMIT;
But we perform the check a second time.
>
> nr_occupied_ptes >= nr_ptes - max_ptes_none
>
> So max_ptes_none=0 + 511 present PTEs + one allowed swap PTE won't even
> call collapse_huge_page() for PMD order.
>
> Shouldn't we account for them in the PMD-order check? Something like:
>
> if (is_pmd_order(order))
> nr_occupied_ptes += unmapped;
As an alternative, we could either 1) skip the check there for
pmd order (as the check was already done); or 2) introduce+maintain
a bitmap that tracks non-present PTEs.
@@ -1475,7 +1477,9 @@ static enum scan_result mthp_collapse(struct mm_struct *mm,
nr_occupied_ptes = bitmap_weight_from(cc->mthp_present_ptes, offset,
offset + nr_ptes);
- if (nr_occupied_ptes >= nr_ptes - max_ptes_none) {
+ /* Check was already done in the caller. */
+ if (is_pmd_order(order) ||
+ nr_occupied_ptes >= nr_ptes - max_ptes_none) {
enum scan_result ret;
collapse_address = address + offset * PAGE_SIZE;
2) would probably be cleanest long-term.
--
Cheers,
David
^ permalink raw reply
* Re: [RFC v1 1/9] kho: split out radix tree tracker into kho_radix.c
From: Pasha Tatashin @ 2026-06-08 14:56 UTC (permalink / raw)
To: Mike Rapoport
Cc: Pasha Tatashin, linux-kselftest, shuah, akpm, linux-mm, skhan,
linux-doc, jasonmiu, linux-kernel, corbet, ran.xiaokai, kexec,
pratyush, graf
In-Reply-To: <178085518028.1648214.13339471022594901667.b4-reply@b4>
On 06-07 20:59, Mike Rapoport wrote:
> On 2026-06-07 16:20:50+00:00, Pasha Tatashin wrote:
> > On 06-07 14:58, Mike Rapoport wrote:
> >
> > > On Fri, 05 Jun 2026 03:32:27 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> > >
> > > It's radix tree data structure implementation, kho memory tracker is it's
> > > user. Please rephrase to keep the semantics clear.
> >
> > Yeap, I will update it.
> >
> > > I don't see much value in moving kexec_handover.o to a separate line,
> > > btw, the same is true for luo_core.o, but it's not important enough to
> > > change.
> >
> > This is purely for consistency. I wanted to use the exact same style in
> > the Makefile instead of having two different ways of declaring the
> > object lists.
> >
> > This:
> > luo-y := \
> > luo_core.o \
> > luo_file.o \
> > luo_flb.o \
> > luo_session.o
> >
> > kho-y := \
> > kexec_handover.o \
> > kho_radix.o \
> > kho_block.o \
> > kho_vmalloc.o
>
> I mean this:
>
> luo-y := luo_core.o \
> luo_file.o \
> luo_flb.o \
> luo_session.o
>
> kho-y := kexec_handover.o \
> kho_radix.o \
> kho_block.o \
> kho_vmalloc.o
Got it, I thought you were against making the consistent :-)
>
>
^ permalink raw reply
* [PATCH v5 00/34] Cleaning up the KVM clock mess
From: David Woodhouse @ 2026-06-08 14:47 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
This is v5 of the series to clean up the KVM clock, rebased onto
tip/timers/ptp (which now includes Thomas's ktime snapshot series and
the read_snapshot patches for hyperv, kvmclock, and vmclock).
The KVM clock has historically suffered from three problems:
1. Imprecision: get_kvmclock_ns() computed the clock from the *host*
TSC without applying guest TSC scaling, causing systemic drift from
the values the guest computes from its own TSC.
2. Unnecessary discontinuities: gratuitous KVM_REQ_MASTERCLOCK_UPDATE
requests caused the master clock reference point to be re-snapshotted,
yanking the guest's clock due to arithmetic precision differences.
3. No precise migration API: the existing KVM_[GS]ET_CLOCK only allows
setting the clock at a given UTC reference time, which is necessarily
imprecise. There was no way to preserve the exact arithmetic
relationship between guest TSC and KVM clock across live migration.
This series addresses all three, and adds new APIs for precise clock
migration and TSC frequency reporting. As an added bonus, it now rips
out the whole pvclock_gtod_data hack which was shadowing the kernel's
timekeeping, and uses ktime snapshots as $DEITY (well, Thomas) intended.
Changes since v4:
- Rebased onto tip/timers/ptp (includes ktime snapshot infrastructure)
- Dropped "WARN if kvm_get_walltime_and_clockread() fails" — the WARN
was spurious during clocksource transitions
- Dropped guest-side "Obtain TSC frequency from CPUID" patches (adopted
by Sean for a separate series)
- Dropped KVM_VCPU_TSC_EFFECTIVE_FREQ
- Fixed false re-enabling of master clock when a single vCPU syncs
multiple times at a mismatched frequency: introduced per-vCPU
cur_tsc_freq_generation counter so each vCPU is counted exactly once
- Unified nr_vcpus_matched_tsc and nr_vcpus_matched_freq to use the
same counting convention (1-based, >= online_vcpus threshold)
- "Avoid gratuitous global clock updates": kept global update in
non-master-clock mode on vCPU load (CLOCK_MONOTONIC_RAW means no NTP
drift but preserving the existing safety); only optimize master clock
- "Xen runstate negative time": refined to update state but not account
time on backwards clock, always update last_steal and guest shared page
- Added "Activate master clock immediately on vCPU creation" to avoid
unnecessary non-master-clock window during VM setup
- New final patches: use ktime_get_snapshot_id() for master clock
reference, then remove pvclock_gtod_data entirely (replaced by direct
ktime_get_raw() + offs_boot computation)
- Added masterclock_offset_test selftest (verifies kvmclock consistency
across vCPUs with different TSC offsets)
- Added xen_cpuid_timing_test selftest
- Added pvclock_migration_test selftest
- Addressed AI reviewer (Sashiko) feedback throughout:
- get_kvmclock(): goto fallback on clock read failure instead of
using uninitialized data; single #ifdef CONFIG_X86_64 block
- kvm_synchronize_tsc(): changed ns to s64 to match function
signature; moved time reads inside tsc_write_lock
- Kill last_tsc fields: use kvm_scale_tsc() subtraction for
backwards TSC instead of zeroing cur_tsc_write
- KVM_[GS]ET_CLOCK_GUEST: validate padding fields, bounds-check
tsc_shift
- pvclock selftest: seqcount loop for torn-read safety, per-vCPU
pvclock addresses, graceful skip when caps unavailable
- KVM_VCPU_TSC_SCALE: return -ENXIO when !has_tsc_control
- UAPI pvclock-abi: added -D__KERNEL__ to xen-hypercalls.sh
- VMX: also clear SECONDARY_EXEC_TSC_SCALING from vmcs_config
David Woodhouse (31):
KVM: x86/xen: Do not corrupt KVM clock in kvm_xen_shared_info_init()
KVM: x86: Improve accuracy of KVM clock when TSC scaling is in force
KVM: x86: Explicitly disable TSC scaling without CONSTANT_TSC
KVM: x86: Activate master clock immediately on vCPU creation
KVM: x86: Add KVM_VCPU_TSC_SCALE and fix the documentation on TSC migration
KVM: x86: Avoid NTP frequency skew for KVM clock on 32-bit host
KVM: x86: Fold __get_kvmclock() into get_kvmclock()
KVM: x86: Restructure get_kvmclock()
KVM: x86: Fix KVM clock precision in get_kvmclock() with TSC scaling
KVM: x86: Use get_kvmclock() in kvm_get_wall_clock_epoch()
KVM: x86: Fix compute_guest_tsc() to handle negative time deltas
KVM: x86: Restructure kvm_guest_time_update() for TSC upscaling
KVM: x86: Simplify and comment kvm_get_time_scale()
KVM: x86: Remove implicit rdtsc() from kvm_compute_l1_tsc_offset()
KVM: x86: Improve synchronization in kvm_synchronize_tsc()
KVM: x86: Kill last_tsc_{nsec,write,offset} fields
KVM: x86: Replace nr_vcpus_matched_tsc count with all_vcpus_matched_tsc bool
KVM: x86: Allow KVM master clock mode when TSCs are offset from each other
KVM: x86: Factor out kvm_use_master_clock()
KVM: x86: Avoid gratuitous global clock updates
KVM: x86/xen: Prevent runstate times from becoming negative
KVM: x86: Avoid redundant masterclock updates from multiple vCPUs
KVM: x86: Remove runtime Xen TSC frequency CPUID update
KVM: x86: Re-synchronize TSC after KVM_SET_TSC_KHZ
KVM: x86: Use ktime_get_snapshot_id() for master clock
KVM: x86: Compute kvmclock base without pvclock_gtod_data
KVM: x86: Replace pvclock_gtod_data vclock_mode with boolean
KVM: x86: Remove pvclock_gtod_data and private timekeeping code
KVM: selftests: Add master clock offset test
KVM: selftests: Add Xen/generic CPUID timing leaf test
KVM: selftests: Add Xen runstate migration test
Jack Allister (3):
UAPI: x86: Move pvclock-abi to UAPI for x86 platforms
KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration
KVM: selftests: Add KVM/PV clock selftest to prove timer correction
Documentation/virt/kvm/api.rst | 37 +
Documentation/virt/kvm/devices/vcpu.rst | 119 ++-
MAINTAINERS | 4 +-
arch/x86/include/asm/kvm_host.h | 16 +-
arch/x86/include/uapi/asm/kvm.h | 6 +
arch/x86/include/{ => uapi}/asm/pvclock-abi.h | 27 +-
arch/x86/kvm/cpuid.c | 16 -
arch/x86/kvm/svm/svm.c | 3 +-
arch/x86/kvm/vmx/vmx.c | 4 +-
arch/x86/kvm/x86.c | 1039 ++++++++++++--------
arch/x86/kvm/xen.c | 30 +-
arch/x86/kvm/xen.h | 13 -
include/uapi/linux/kvm.h | 3 +
scripts/xen-hypercalls.sh | 2 +-
tools/testing/selftests/kvm/Makefile.kvm | 4 +
.../selftests/kvm/x86/masterclock_offset_test.c | 180 ++++
.../selftests/kvm/x86/pvclock_migration_test.c | 382 +++++++
tools/testing/selftests/kvm/x86/pvclock_test.c | 441 +++++++++
.../selftests/kvm/x86/xen_cpuid_timing_test.c | 230 +++++
.../testing/selftests/kvm/x86/xen_migration_test.c | 194 ++++
20 files changed, 2263 insertions(+), 487 deletions(-)
base-commit: bc484a5096732cd858771cccd3164ec985bdc03d
^ permalink raw reply
* [PATCH v5 16/34] KVM: x86: Simplify and comment kvm_get_time_scale()
From: David Woodhouse @ 2026-06-08 14:47 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
The kvm_get_time_scale() function was entirely opaque. Add comments
explaining what it does: compute a fixed-point multiplier and shift for
converting TSC ticks to nanoseconds via pvclock_scale_delta().
Rename the local variables from the cryptic tps64/tps32/scaled64 to
base_hz_u64/base32/scaled_hz_u64 to make the code self-documenting.
The "tps32" name stood for "Ticks Per Second" but was misleading since
it held the shifted base frequency, not a tick count.
No functional change.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
---
arch/x86/kvm/x86.c | 55 +++++++++++++++++++++++++++++++++-------------
1 file changed, 40 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 92e32d720523..a6c31a0d9955 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2472,32 +2472,57 @@ static uint32_t div_frac(uint32_t dividend, uint32_t divisor)
return dividend;
}
-static void kvm_get_time_scale(uint64_t scaled_hz, uint64_t base_hz,
+static void kvm_get_time_scale(u64 scaled_hz, u64 base_hz,
s8 *pshift, u32 *pmultiplier)
{
- uint64_t scaled64;
- int32_t shift = 0;
- uint64_t tps64;
- uint32_t tps32;
+ u64 scaled_hz_u64 = scaled_hz;
+ s32 shift = 0;
+ u64 base_hz_u64;
+ u32 base32;
- tps64 = base_hz;
- scaled64 = scaled_hz;
- while (tps64 > scaled64*2 || tps64 & 0xffffffff00000000ULL) {
- tps64 >>= 1;
+ /*
+ * This function calculates a fixed-point multiplier and shift such
+ * that:
+ * time_ns = (tsc_cycles << shift) * multiplier >> 32
+ *
+ * Where tsc_cycles tick at base_hz, and time_ns should count at
+ * scaled_hz (typically NSEC_PER_SEC for a TSC→nanoseconds conversion).
+ *
+ * The multiplier is: (scaled_hz << 32) / base_hz, adjusted by shift
+ * to keep everything in range.
+ */
+
+ base_hz_u64 = base_hz;
+
+ /*
+ * Start by shifting base_hz right until it fits in 32 bits, and
+ * is lower than double the target rate. This introduces a negative
+ * shift value which would result in pvclock_scale_delta() shifting
+ * the actual tick count right before performing the multiplication.
+ */
+ while (base_hz_u64 > scaled_hz_u64 * 2 || base_hz_u64 >> 32) {
+ base_hz_u64 >>= 1;
shift--;
}
- tps32 = (uint32_t)tps64;
- while (tps32 <= scaled64 || scaled64 & 0xffffffff00000000ULL) {
- if (scaled64 & 0xffffffff00000000ULL || tps32 & 0x80000000)
- scaled64 >>= 1;
+ /* Now the shifted base_hz fits in 32 bits. */
+ base32 = (u32)base_hz_u64;
+
+ /*
+ * Next, shift scaled_hz right until it fits in 32 bits, and ensure
+ * that the shifted base_hz is strictly larger (so that the result of the
+ * final division also fits in 32 bits).
+ */
+ while (base32 <= scaled_hz_u64 || scaled_hz_u64 >> 32) {
+ if (scaled_hz_u64 >> 32 || base32 & BIT(31))
+ scaled_hz_u64 >>= 1;
else
- tps32 <<= 1;
+ base32 <<= 1;
shift++;
}
*pshift = shift;
- *pmultiplier = div_frac(scaled64, tps32);
+ *pmultiplier = div_frac(scaled_hz_u64, base32);
}
#ifdef CONFIG_X86_64
--
2.54.0
^ permalink raw reply related
* [PATCH v5 32/34] KVM: x86: Compute kvmclock base without pvclock_gtod_data
From: David Woodhouse @ 2026-06-08 14:48 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
get_kvmclock_base_ns() needs CLOCK_MONOTONIC_RAW + offs_boot. Compute
this directly rather than reading offs_boot from the pvclock_gtod_data
private copy. offs_boot only changes at suspend/resume so does not
need to be atomically paired with the raw clock read.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Assisted-by: Kiro:claude-opus-4.6-1m
---
arch/x86/kvm/x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2713aebb96ae..c18947c5b63f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2402,7 +2402,7 @@ static void update_pvclock_gtod(struct timekeeper *tk)
static s64 get_kvmclock_base_ns(void)
{
/* Count up from boot time, but with the frequency of the raw clock. */
- return ktime_to_ns(ktime_add(ktime_get_raw(), pvclock_gtod_data.offs_boot));
+ return ktime_to_ns(ktime_mono_to_any(ktime_get_raw(), TK_OFFS_BOOT));
}
static void kvm_write_wall_clock(struct kvm *kvm, gpa_t wall_clock, int sec_hi_ofs)
--
2.54.0
^ permalink raw reply related
* [PATCH v5 23/34] KVM: x86: Factor out kvm_use_master_clock()
From: David Woodhouse @ 2026-06-08 14:48 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
Both kvm_track_tsc_matching() and pvclock_update_vm_gtod_copy() make a
decision about whether the KVM clock should be in master clock mode.
They used *different* criteria for the decision though. This isn't
really a problem; it only has the potential to cause unnecessary
invocations of KVM_REQ_MASTERCLOCK_UPDATE if the masterclock was
disabled due to TSC going backwards, or the guest using the old MSR.
But it isn't pretty.
Factor the decision out to a single function. And document the
historical reason why it's disabled for guests that use the old
MSR_KVM_SYSTEM_TIME.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
---
arch/x86/kvm/x86.c | 40 ++++++++++++++++++++++++++++++----------
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 86c30be4c5d2..72fb4620a5ba 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2638,11 +2638,30 @@ static inline bool gtod_is_based_on_tsc(int mode)
{
return mode == VDSO_CLOCKMODE_TSC || mode == VDSO_CLOCKMODE_HVCLOCK;
}
-#endif
+
+static bool kvm_use_master_clock(struct kvm *kvm)
+{
+ struct kvm_arch *ka = &kvm->arch;
+
+ /*
+ * The 'old kvmclock' check is a workaround (from 2015) for a
+ * SUSE 2.6.16 kernel that didn't boot if the system_time in
+ * its kvmclock was too far behind the current time. So the
+ * mode of just setting the reference point and allowing time
+ * to proceed linearly from there makes it fail to boot.
+ * Despite that being kind of the *point* of the way the clock
+ * is exposed to the guest. By coincidence, the offending
+ * kernels used the old MSR_KVM_SYSTEM_TIME, which was moved
+ * only because it resided in the wrong number range. So the
+ * workaround is activated for *all* guests using the old MSR.
+ */
+ return ka->all_vcpus_matched_freq &&
+ !ka->backwards_tsc_observed &&
+ !ka->boot_vcpu_runs_old_kvmclock;
+}
static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool new_generation)
{
-#ifdef CONFIG_X86_64
struct kvm_arch *ka = &vcpu->kvm->arch;
struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
@@ -2677,7 +2696,7 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool new_generation)
* are fine — each vCPU's pvclock has its own tsc_timestamp that
* accounts for its offset.
*/
- bool use_master_clock = ka->all_vcpus_matched_freq &&
+ bool use_master_clock = kvm_use_master_clock(vcpu->kvm) &&
gtod_is_based_on_tsc(gtod->clock.vclock_mode);
/*
@@ -2693,8 +2712,11 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool new_generation)
trace_kvm_track_tsc(vcpu->vcpu_id, ka->nr_vcpus_matched_tsc,
atomic_read(&vcpu->kvm->online_vcpus),
ka->use_master_clock, gtod->clock.vclock_mode);
-#endif
}
+#else
+static inline void kvm_track_tsc_matching(struct kvm_vcpu *vcpu,
+ bool new_generation) {}
+#endif
/*
* Multiply tsc by a fixed point number represented by ratio.
@@ -3216,10 +3238,9 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
#ifdef CONFIG_X86_64
struct kvm_arch *ka = &kvm->arch;
int vclock_mode;
- bool host_tsc_clocksource, vcpus_matched;
+ bool host_tsc_clocksource;
lockdep_assert_held(&kvm->arch.tsc_write_lock);
- vcpus_matched = ka->all_vcpus_matched_freq;
/*
* If the host uses TSC clock, then passthrough TSC as stable
@@ -3229,9 +3250,8 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
&ka->master_kernel_ns,
&ka->master_cycle_now);
- ka->use_master_clock = host_tsc_clocksource && vcpus_matched
- && !ka->backwards_tsc_observed
- && !ka->boot_vcpu_runs_old_kvmclock;
+ ka->use_master_clock = host_tsc_clocksource &&
+ kvm_use_master_clock(kvm);
if (ka->use_master_clock) {
u64 tsc_hz;
@@ -3259,7 +3279,7 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
vclock_mode = pvclock_gtod_data.clock.vclock_mode;
trace_kvm_update_master_clock(ka->use_master_clock, vclock_mode,
- vcpus_matched);
+ ka->all_vcpus_matched_freq);
#endif
}
--
2.54.0
^ permalink raw reply related
* [PATCH v5 18/34] KVM: x86: Improve synchronization in kvm_synchronize_tsc()
From: David Woodhouse @ 2026-06-08 14:47 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
When synchronizing to an existing TSC (either by explicitly writing
zero, or the legacy hack where the TSC is written within one second's
worth of the previously written TSC), the last_tsc_write and
last_tsc_nsec values were being misrecorded by __kvm_synchronize_tsc().
The *unsynchronized* value of the TSC (perhaps even zero) was being
recorded, along with the current time at which kvm_synchronize_tsc()
was called. This could cause *subsequent* writes to fail to synchronize
correctly.
Fix that by resetting {data, ns} to the previous values before passing
them to __kvm_synchronize_tsc() when synchronization is detected.
Except in the case where the TSC is unstable and *has* to be synthesised
from the host clock, in which case attempt to create a nsec/tsc pair
which is on the correct line.
Furthermore, there were *three* different TSC reads used for calculating
the "current" time, all slightly different from each other. Fix that by
using kvm_get_time_and_clockread() where possible and using the same
host_tsc value in all cases.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
---
arch/x86/kvm/x86.c | 33 +++++++++++++++++++++++++++++----
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index bce4c7a6a6fe..c8c0633263fb 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -203,6 +203,9 @@ module_param(mitigate_smt_rsb, bool, 0444);
* usermode, e.g. SYSCALL MSRs and TSC_AUX, can be deferred until the CPU
* returns to userspace, i.e. the kernel can run with the guest's value.
*/
+#ifdef CONFIG_X86_64
+static bool kvm_get_time_and_clockread(s64 *kernel_ns, u64 *tsc_timestamp);
+#endif
#define KVM_MAX_NR_USER_RETURN_MSRS 16
struct kvm_user_return_msrs {
@@ -2854,14 +2857,23 @@ static void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)
{
u64 data = user_value ? *user_value : 0;
struct kvm *kvm = vcpu->kvm;
- u64 offset, ns, elapsed;
+ u64 offset, host_tsc, elapsed;
+ s64 ns;
unsigned long flags;
bool matched = false;
bool synchronizing = false;
raw_spin_lock_irqsave(&kvm->arch.tsc_write_lock, flags);
- offset = kvm_compute_l1_tsc_offset(vcpu, rdtsc(), data);
- ns = get_kvmclock_base_ns();
+
+#ifdef CONFIG_X86_64
+ if (!kvm_get_time_and_clockread(&ns, &host_tsc))
+#endif
+ {
+ host_tsc = rdtsc();
+ ns = get_kvmclock_base_ns();
+ }
+
+ offset = kvm_compute_l1_tsc_offset(vcpu, host_tsc, data);
elapsed = ns - kvm->arch.last_tsc_nsec;
if (vcpu->arch.virtual_tsc_khz) {
@@ -2904,12 +2916,25 @@ static void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)
*/
if (synchronizing &&
vcpu->arch.virtual_tsc_khz == kvm->arch.last_tsc_khz) {
+ /*
+ * If synchronizing, the "last written" TSC value/time
+ * recorded by __kvm_synchronize_tsc() should not change
+ * (i.e. should be precisely the same as the existing
+ * generation).
+ */
+ data = kvm->arch.last_tsc_write;
+
if (!kvm_check_tsc_unstable()) {
offset = kvm->arch.cur_tsc_offset;
+ ns = kvm->arch.cur_tsc_nsec;
} else {
+ /*
+ * ...unless the TSC is unstable and has to be
+ * synthesised from the host clock in nanoseconds.
+ */
u64 delta = nsec_to_cycles(vcpu, elapsed);
data += delta;
- offset = kvm_compute_l1_tsc_offset(vcpu, rdtsc(), data);
+ offset = kvm_compute_l1_tsc_offset(vcpu, host_tsc, data);
}
matched = true;
}
--
2.54.0
^ permalink raw reply related
* [PATCH v5 03/34] UAPI: x86: Move pvclock-abi to UAPI for x86 platforms
From: David Woodhouse @ 2026-06-08 14:47 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: Jack Allister <jalliste@amazon.com>
A subsequent commit will provide a new KVM interface for performing a
fixup/correction of the KVM clock against the reference TSC. The
KVM_[GS]ET_CLOCK_GUEST API requires a pvclock_vcpu_time_info, as such
the caller must know about this definition.
Move the definition to the UAPI folder so that it is exported to
usermode and also change the type definitions to use the standard for
UAPI exports.
Signed-off-by: Jack Allister <jalliste@amazon.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
---
MAINTAINERS | 4 +--
arch/x86/include/{ => uapi}/asm/pvclock-abi.h | 27 ++++++++++---------
scripts/xen-hypercalls.sh | 2 +-
3 files changed, 18 insertions(+), 15 deletions(-)
rename arch/x86/include/{ => uapi}/asm/pvclock-abi.h (82%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 882214b0e7db..dc0f6516beb4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14402,7 +14402,7 @@ S: Supported
T: git git://git.kernel.org/pub/scm/virt/kvm/kvm.git
F: arch/um/include/asm/kvm_para.h
F: arch/x86/include/asm/kvm_para.h
-F: arch/x86/include/asm/pvclock-abi.h
+F: arch/x86/include/uapi/asm/pvclock-abi.h
F: arch/x86/include/uapi/asm/kvm_para.h
F: arch/x86/kernel/kvm.c
F: arch/x86/kernel/kvmclock.c
@@ -29081,7 +29081,7 @@ R: Boris Ostrovsky <boris.ostrovsky@oracle.com>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
S: Supported
F: arch/x86/configs/xen.config
-F: arch/x86/include/asm/pvclock-abi.h
+F: arch/x86/include/uapi/asm/pvclock-abi.h
F: arch/x86/include/asm/xen/
F: arch/x86/platform/pvh/
F: arch/x86/xen/
diff --git a/arch/x86/include/asm/pvclock-abi.h b/arch/x86/include/uapi/asm/pvclock-abi.h
similarity index 82%
rename from arch/x86/include/asm/pvclock-abi.h
rename to arch/x86/include/uapi/asm/pvclock-abi.h
index b9fece5fc96d..6d70cf640362 100644
--- a/arch/x86/include/asm/pvclock-abi.h
+++ b/arch/x86/include/uapi/asm/pvclock-abi.h
@@ -1,6 +1,9 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
#ifndef _ASM_X86_PVCLOCK_ABI_H
#define _ASM_X86_PVCLOCK_ABI_H
+
+#include <linux/types.h>
+
#ifndef __ASSEMBLER__
/*
@@ -24,20 +27,20 @@
*/
struct pvclock_vcpu_time_info {
- u32 version;
- u32 pad0;
- u64 tsc_timestamp;
- u64 system_time;
- u32 tsc_to_system_mul;
- s8 tsc_shift;
- u8 flags;
- u8 pad[2];
+ __u32 version;
+ __u32 pad0;
+ __u64 tsc_timestamp;
+ __u64 system_time;
+ __u32 tsc_to_system_mul;
+ __s8 tsc_shift;
+ __u8 flags;
+ __u8 pad[2];
} __attribute__((__packed__)); /* 32 bytes */
struct pvclock_wall_clock {
- u32 version;
- u32 sec;
- u32 nsec;
+ __u32 version;
+ __u32 sec;
+ __u32 nsec;
} __attribute__((__packed__));
#define PVCLOCK_TSC_STABLE_BIT (1 << 0)
diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
index f18b00843df3..51a722198997 100755
--- a/scripts/xen-hypercalls.sh
+++ b/scripts/xen-hypercalls.sh
@@ -5,7 +5,7 @@ shift
in="$@"
for i in $in; do
- eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
+ eval $CPP -D__KERNEL__ $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
done | \
awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
END { print "/* auto-generated by scripts/xen-hypercall.sh */"
--
2.54.0
^ permalink raw reply related
* [PATCH v5 10/34] KVM: x86: Fold __get_kvmclock() into get_kvmclock()
From: David Woodhouse @ 2026-06-08 14:47 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
There is no need for the separate __get_kvmclock() helper; just inline
its body into get_kvmclock() within the seqcount retry loop.
No functional change.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/kvm/x86.c | 63 +++++++++++++++++++++-------------------------
1 file changed, 28 insertions(+), 35 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 50bd2871b051..fce898811fe7 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3200,50 +3200,43 @@ static unsigned long get_cpu_tsc_khz(void)
return __this_cpu_read(cpu_tsc_khz);
}
-/* Called within read_seqcount_begin/retry for kvm->pvclock_sc. */
-static void __get_kvmclock(struct kvm *kvm, struct kvm_clock_data *data)
+static void get_kvmclock(struct kvm *kvm, struct kvm_clock_data *data)
{
struct kvm_arch *ka = &kvm->arch;
struct pvclock_vcpu_time_info hv_clock;
+ unsigned int seq;
- /* both __this_cpu_read() and rdtsc() should be on the same cpu */
- get_cpu();
+ do {
+ seq = read_seqcount_begin(&ka->pvclock_sc);
- data->flags = 0;
- if (ka->use_master_clock &&
- (static_cpu_has(X86_FEATURE_CONSTANT_TSC) || __this_cpu_read(cpu_tsc_khz))) {
+ /* both __this_cpu_read() and rdtsc() should be on the same cpu */
+ get_cpu();
+
+ data->flags = 0;
+ if (ka->use_master_clock &&
+ (static_cpu_has(X86_FEATURE_CONSTANT_TSC) || __this_cpu_read(cpu_tsc_khz))) {
#ifdef CONFIG_X86_64
- struct timespec64 ts;
+ struct timespec64 ts;
- if (kvm_get_walltime_and_clockread(&ts, &data->host_tsc)) {
- data->realtime = ts.tv_nsec + NSEC_PER_SEC * ts.tv_sec;
- data->flags |= KVM_CLOCK_REALTIME | KVM_CLOCK_HOST_TSC;
- } else
+ if (kvm_get_walltime_and_clockread(&ts, &data->host_tsc)) {
+ data->realtime = ts.tv_nsec + NSEC_PER_SEC * ts.tv_sec;
+ data->flags |= KVM_CLOCK_REALTIME | KVM_CLOCK_HOST_TSC;
+ } else
#endif
- data->host_tsc = rdtsc();
-
- data->flags |= KVM_CLOCK_TSC_STABLE;
- hv_clock.tsc_timestamp = ka->master_cycle_now;
- hv_clock.system_time = ka->master_kernel_ns + ka->kvmclock_offset;
- kvm_get_time_scale(NSEC_PER_SEC, get_cpu_tsc_khz() * 1000LL,
- &hv_clock.tsc_shift,
- &hv_clock.tsc_to_system_mul);
- data->clock = __pvclock_read_cycles(&hv_clock, data->host_tsc);
- } else {
- data->clock = get_kvmclock_base_ns() + ka->kvmclock_offset;
- }
-
- put_cpu();
-}
-
-static void get_kvmclock(struct kvm *kvm, struct kvm_clock_data *data)
-{
- struct kvm_arch *ka = &kvm->arch;
- unsigned seq;
+ data->host_tsc = rdtsc();
+
+ data->flags |= KVM_CLOCK_TSC_STABLE;
+ hv_clock.tsc_timestamp = ka->master_cycle_now;
+ hv_clock.system_time = ka->master_kernel_ns + ka->kvmclock_offset;
+ kvm_get_time_scale(NSEC_PER_SEC, get_cpu_tsc_khz() * 1000LL,
+ &hv_clock.tsc_shift,
+ &hv_clock.tsc_to_system_mul);
+ data->clock = __pvclock_read_cycles(&hv_clock, data->host_tsc);
+ } else {
+ data->clock = get_kvmclock_base_ns() + ka->kvmclock_offset;
+ }
- do {
- seq = read_seqcount_begin(&ka->pvclock_sc);
- __get_kvmclock(kvm, data);
+ put_cpu();
} while (read_seqcount_retry(&ka->pvclock_sc, seq));
}
--
2.54.0
^ permalink raw reply related
* [PATCH v5 04/34] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration
From: David Woodhouse @ 2026-06-08 14:47 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: Jack Allister <jalliste@amazon.com>
In the common case (where kvm->arch.use_master_clock is true), the KVM
clock is defined as a simple arithmetic function of the guest TSC, based
on a reference point stored in kvm->arch.master_kernel_ns and
kvm->arch.master_cycle_now.
The existing KVM_[GS]ET_CLOCK functionality does not allow for this
relationship to be precisely saved and restored by userspace. All it can
currently do is set the KVM clock at a given UTC reference time, which
is necessarily imprecise.
So on live update, the guest TSC can remain cycle accurate at precisely
the same offset from the host TSC, but there is no way for userspace to
restore the KVM clock accurately.
Even on live migration to a new host, where the accuracy of the guest
time-keeping is fundamentally limited by the accuracy of wallclock
synchronization between the source and destination hosts, the clock jump
experienced by the guest's TSC and its KVM clock should at least be
*consistent*. Even when the guest TSC suffers a discontinuity, its KVM
clock should still remain the *same* arithmetic function of the guest
TSC, and not suffer an *additional* discontinuity.
To allow for accurate migration of the KVM clock, add per-vCPU ioctls
which save and restore the actual PV clock info in
pvclock_vcpu_time_info.
The restoration in KVM_SET_CLOCK_GUEST works by creating a new reference
point in time just as kvm_update_masterclock() does, and calculating the
corresponding guest TSC value. This guest TSC value is then passed
through the user-provided pvclock structure to generate the *intended*
KVM clock value at that point in time, and through the *actual* KVM
clock calculation. Then kvm->arch.kvmclock_offset is adjusted to
eliminate the difference.
Where kvm->arch.use_master_clock is false (because the host TSC is
unreliable, or the guest TSCs are configured strangely), the KVM clock
is *not* defined as a function of the guest TSC so KVM_GET_CLOCK_GUEST
returns an error. In this case, as documented, userspace shall use the
legacy KVM_GET_CLOCK ioctl. The loss of precision is acceptable in this
case since the clocks are imprecise in this mode anyway.
On *restoration*, if kvm->arch.use_master_clock is false, an error is
returned for similar reasons and userspace shall fall back to using
KVM_SET_CLOCK. This does mean that, as documented, userspace needs to
use *both* KVM_GET_CLOCK_GUEST and KVM_GET_CLOCK and send both results
with the migration data (unless the intent is to refuse to resume on a
host with bad TSC).
Co-developed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Jack Allister <jalliste@amazon.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Cc: Dongli Zhang <dongli.zhang@oracle.com>
---
Documentation/virt/kvm/api.rst | 37 ++++++++
arch/x86/kvm/x86.c | 164 +++++++++++++++++++++++++++++++++
include/uapi/linux/kvm.h | 3 +
3 files changed, 204 insertions(+)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 52bbbb553ce1..2268b4442df6 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6553,6 +6553,43 @@ KVM_S390_KEYOP_SSKE
Sets the storage key for the guest address ``guest_addr`` to the key
specified in ``key``, returning the previous value in ``key``.
+4.145 KVM_GET_CLOCK_GUEST
+----------------------------
+
+:Capability: none
+:Architectures: x86_64
+:Type: vcpu ioctl
+:Parameters: struct pvclock_vcpu_time_info (out)
+:Returns: 0 on success, <0 on error
+
+Retrieves the current time information structure used for KVM/PV clocks,
+in precisely the form advertised to the guest vCPU, which gives parameters
+for a direct conversion from a guest TSC value to nanoseconds.
+
+When the KVM clock is not in "master clock" mode, for example because the
+host TSC is unreliable or the guest TSCs are oddly configured, the KVM clock
+is actually defined by the host CLOCK_MONOTONIC_RAW instead of the guest TSC.
+In this case, the KVM_GET_CLOCK_GUEST ioctl returns -EINVAL.
+
+4.146 KVM_SET_CLOCK_GUEST
+----------------------------
+
+:Capability: none
+:Architectures: x86_64
+:Type: vcpu ioctl
+:Parameters: struct pvclock_vcpu_time_info (in)
+:Returns: 0 on success, <0 on error
+
+Sets the KVM clock (for the whole VM) in terms of the vCPU TSC, using the
+pvclock structure as returned by KVM_GET_CLOCK_GUEST. This allows the precise
+arithmetic relationship between guest TSC and KVM clock to be preserved by
+userspace across migration.
+
+When the KVM clock is not in "master clock" mode, and the KVM clock is actually
+defined by the host CLOCK_MONOTONIC_RAW, this ioctl returns -EINVAL. Userspace
+may choose to set the clock using the less precise KVM_SET_CLOCK ioctl, or may
+choose to fail, denying migration to a host whose TSC is misbehaving.
+
.. _kvm_run:
5. The kvm_run structure
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d9ef165df6a1..b7e5f6e3dc6c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6205,6 +6205,162 @@ static int kvm_get_reg_list(struct kvm_vcpu *vcpu,
return 0;
}
+#ifdef CONFIG_X86_64
+static int kvm_vcpu_ioctl_get_clock_guest(struct kvm_vcpu *v, void __user *argp)
+{
+ struct pvclock_vcpu_time_info hv_clock = {};
+ struct kvm_vcpu_arch *vcpu = &v->arch;
+ struct kvm_arch *ka = &v->kvm->arch;
+ unsigned int seq;
+
+ /*
+ * If KVM_REQ_CLOCK_UPDATE is already pending, or if the pvclock
+ * has never been generated at all, call kvm_guest_time_update().
+ */
+ if (kvm_check_request(KVM_REQ_CLOCK_UPDATE, v) || !vcpu->hw_tsc_hz) {
+ int idx = srcu_read_lock(&v->kvm->srcu);
+ int ret = kvm_guest_time_update(v);
+
+ srcu_read_unlock(&v->kvm->srcu, idx);
+ if (ret)
+ return -EINVAL;
+ }
+
+ /*
+ * Reconstruct the pvclock from the master clock state, matching
+ * exactly what kvm_guest_time_update() writes to the guest.
+ */
+ do {
+ seq = read_seqcount_begin(&ka->pvclock_sc);
+
+ if (!ka->use_master_clock)
+ return -EINVAL;
+
+ hv_clock.tsc_timestamp = kvm_read_l1_tsc(v, ka->master_cycle_now);
+ hv_clock.system_time = ka->master_kernel_ns + ka->kvmclock_offset;
+ } while (read_seqcount_retry(&ka->pvclock_sc, seq));
+
+ hv_clock.tsc_shift = vcpu->pvclock_tsc_shift;
+ hv_clock.tsc_to_system_mul = vcpu->pvclock_tsc_mul;
+ hv_clock.flags = PVCLOCK_TSC_STABLE_BIT;
+
+ if (copy_to_user(argp, &hv_clock, sizeof(hv_clock)))
+ return -EFAULT;
+
+ return 0;
+}
+
+/*
+ * Reverse the calculation in the hv_clock definition.
+ *
+ * time_ns = ( (cycles << shift) * mul ) >> 32;
+ * (although shift can be negative, so that's bad C)
+ *
+ * So for a single second,
+ * NSEC_PER_SEC = ( ( FREQ_HZ << shift) * mul ) >> 32
+ * NSEC_PER_SEC << 32 = ( FREQ_HZ << shift ) * mul
+ * ( NSEC_PER_SEC << 32 ) / mul = FREQ_HZ << shift
+ * ( NSEC_PER_SEC << 32 ) / mul ) >> shift = FREQ_HZ
+ */
+static u64 hvclock_to_hz(u32 mul, s8 shift)
+{
+ u64 tm = NSEC_PER_SEC << 32;
+
+ /* Maximise precision. Shift right until the top bit is set */
+ tm <<= 2;
+ shift += 2;
+
+ /* While 'mul' is even, increase the shift *after* the division */
+ while (!(mul & 1)) {
+ shift++;
+ mul >>= 1;
+ }
+
+ tm /= mul;
+
+ if (shift > 0)
+ return tm >> shift;
+ else
+ return tm << -shift;
+}
+
+static int kvm_vcpu_ioctl_set_clock_guest(struct kvm_vcpu *v, void __user *argp)
+{
+ struct pvclock_vcpu_time_info user_hv_clock;
+ struct kvm *kvm = v->kvm;
+ struct kvm_arch *ka = &kvm->arch;
+ u64 curr_tsc_hz, user_tsc_hz;
+ u64 user_clk_ns;
+ u64 guest_tsc;
+ int rc = 0;
+
+ if (copy_from_user(&user_hv_clock, argp, sizeof(user_hv_clock)))
+ return -EFAULT;
+
+ if (user_hv_clock.pad0 || user_hv_clock.pad[0] || user_hv_clock.pad[1])
+ return -EINVAL;
+
+ if (!user_hv_clock.tsc_to_system_mul)
+ return -EINVAL;
+
+ if (user_hv_clock.tsc_shift < -32 || user_hv_clock.tsc_shift > 32)
+ return -EINVAL;
+
+ user_tsc_hz = hvclock_to_hz(user_hv_clock.tsc_to_system_mul,
+ user_hv_clock.tsc_shift);
+
+ kvm_hv_request_tsc_page_update(kvm);
+
+ /*
+ * kvm_start_pvclock_update() takes tsc_write_lock and opens
+ * the pvclock seqcount; kvm_end_pvclock_update() closes both.
+ * All clock state modifications between them are atomic with
+ * respect to readers in kvm_guest_time_update().
+ */
+ kvm_start_pvclock_update(kvm);
+ pvclock_update_vm_gtod_copy(kvm);
+
+ if (!ka->use_master_clock) {
+ rc = -EINVAL;
+ goto out;
+ }
+
+ curr_tsc_hz = (u64)get_cpu_tsc_khz() * 1000;
+ if (unlikely(curr_tsc_hz == 0)) {
+ rc = -EINVAL;
+ goto out;
+ }
+
+ if (kvm_caps.has_tsc_control)
+ curr_tsc_hz = kvm_scale_tsc(curr_tsc_hz,
+ v->arch.l1_tsc_scaling_ratio);
+
+ /*
+ * Allow for a discrepancy of 1 kHz either way between the TSC
+ * frequency used to generate the user's pvclock and the current
+ * host's measured frequency, since they may not precisely match.
+ */
+ if (user_tsc_hz < curr_tsc_hz - 1000 ||
+ user_tsc_hz > curr_tsc_hz + 1000) {
+ rc = -ERANGE;
+ goto out;
+ }
+
+ /*
+ * Calculate the guest TSC at the new reference point, and the
+ * corresponding KVM clock value according to user_hv_clock.
+ * Adjust kvmclock_offset so both definitions agree.
+ */
+ guest_tsc = kvm_read_l1_tsc(v, ka->master_cycle_now);
+ user_clk_ns = __pvclock_read_cycles(&user_hv_clock, guest_tsc);
+ ka->kvmclock_offset = user_clk_ns - ka->master_kernel_ns;
+
+out:
+ kvm_end_pvclock_update(kvm);
+ return rc;
+}
+#endif
+
long kvm_arch_vcpu_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg)
{
@@ -6605,6 +6761,14 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
srcu_read_unlock(&vcpu->kvm->srcu, idx);
break;
}
+#ifdef CONFIG_X86_64
+ case KVM_SET_CLOCK_GUEST:
+ r = kvm_vcpu_ioctl_set_clock_guest(vcpu, argp);
+ break;
+ case KVM_GET_CLOCK_GUEST:
+ r = kvm_vcpu_ioctl_get_clock_guest(vcpu, argp);
+ break;
+#endif
#ifdef CONFIG_KVM_HYPERV
case KVM_GET_SUPPORTED_HV_CPUID:
r = kvm_ioctl_get_supported_hv_cpuid(vcpu, argp);
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 6c8afa2047bf..9b50191b859c 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1669,4 +1669,7 @@ struct kvm_pre_fault_memory {
__u64 padding[5];
};
+#define KVM_SET_CLOCK_GUEST _IOW(KVMIO, 0xd6, struct pvclock_vcpu_time_info)
+#define KVM_GET_CLOCK_GUEST _IOR(KVMIO, 0xd7, struct pvclock_vcpu_time_info)
+
#endif /* __LINUX_KVM_H */
--
2.54.0
^ permalink raw reply related
* [PATCH v5 29/34] KVM: x86: Re-synchronize TSC after KVM_SET_TSC_KHZ
From: David Woodhouse @ 2026-06-08 14:48 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
KVM_SET_TSC_KHZ changes the vCPU's TSC scaling ratio but does not
update the VM-wide cur_tsc_scaling_ratio used by get_kvmclock().
This causes get_kvmclock() to use a stale (default 1:1) ratio when
computing the KVM clock, leading to drift between the host-side
kvmclock and what the guest observes.
Fix this by calling kvm_synchronize_tsc() after changing the TSC
frequency. This:
- Updates cur_tsc_scaling_ratio (consumed by pvclock_update_vm_gtod_copy)
- Ensures the TSC value is continuous across the frequency change
- Triggers kvm_track_tsc_matching() for proper masterclock handling
- Allows subsequent vCPUs to synchronize via the 1-second slop hack
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/kvm/x86.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 54d4b1b3cfe4..96250264d403 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -206,6 +206,7 @@ module_param(mitigate_smt_rsb, bool, 0444);
#ifdef CONFIG_X86_64
static bool kvm_get_time_and_clockread(s64 *kernel_ns, u64 *tsc_timestamp);
#endif
+static void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value);
#define KVM_MAX_NR_USER_RETURN_MSRS 16
struct kvm_user_return_msrs {
@@ -2611,7 +2612,20 @@ static int kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz)
user_tsc_khz, thresh_lo, thresh_hi);
use_scaling = 1;
}
- return set_tsc_khz(vcpu, user_tsc_khz, use_scaling);
+ if (set_tsc_khz(vcpu, user_tsc_khz, use_scaling))
+ return -1;
+
+ /*
+ * Re-synchronize the TSC after changing frequency. This ensures
+ * cur_tsc_scaling_ratio is updated (used by get_kvmclock) and
+ * the TSC value is continuous across the frequency change.
+ */
+ {
+ u64 tsc = kvm_read_l1_tsc(vcpu, rdtsc());
+
+ kvm_synchronize_tsc(vcpu, &tsc);
+ }
+ return 0;
}
static u64 compute_guest_tsc(struct kvm_vcpu *vcpu, s64 kernel_ns)
--
2.54.0
^ permalink raw reply related
* [PATCH v5 20/34] KVM: x86: Replace nr_vcpus_matched_tsc count with all_vcpus_matched_tsc bool
From: David Woodhouse @ 2026-06-08 14:48 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
Using a count and comparing with kvm->online_vcpus was always racy
because a new vCPU could be created while kvm_track_tsc_matching() was
running and comparing with kvm->online_vcpus. That variable is only
atomic with respect to itself; kvm_arch_vcpu_create() runs before
kvm->online_vcpus is incremented for the new vCPU.
Replace the count with a boolean that is set in kvm_track_tsc_matching()
after comparing the count, and cleared when a new TSC generation starts.
The boolean is consumed by pvclock_update_vm_gtod_copy() under the
tsc_write_lock, which serializes against __kvm_synchronize_tsc().
Keep the count for now as it's still used in the trace event.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/x86.c | 10 ++++++----
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 59298a8f78eb..eb81f90284ba 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1492,6 +1492,7 @@ struct kvm_arch {
u64 cur_tsc_write;
u64 cur_tsc_offset;
u64 cur_tsc_generation;
+ bool all_vcpus_matched_tsc;
int nr_vcpus_matched_tsc;
u32 default_tsc_khz;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index bbd642e0dc54..ac66f8e7116f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2651,8 +2651,10 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool new_generation)
* and all vCPUs must have matching TSCs. Note, the count for matching
* vCPUs doesn't include the reference vCPU, hence "+1".
*/
- bool use_master_clock = (ka->nr_vcpus_matched_tsc + 1 ==
- atomic_read(&vcpu->kvm->online_vcpus)) &&
+ ka->all_vcpus_matched_tsc = (ka->nr_vcpus_matched_tsc + 1 ==
+ atomic_read(&vcpu->kvm->online_vcpus));
+
+ bool use_master_clock = ka->all_vcpus_matched_tsc &&
gtod_is_based_on_tsc(gtod->clock.vclock_mode);
/*
@@ -2837,6 +2839,7 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc,
kvm->arch.cur_tsc_write = tsc;
kvm->arch.cur_tsc_offset = offset;
kvm->arch.nr_vcpus_matched_tsc = 0;
+ kvm->arch.all_vcpus_matched_tsc = false;
} else if (vcpu->arch.this_tsc_generation != kvm->arch.cur_tsc_generation) {
kvm->arch.nr_vcpus_matched_tsc++;
}
@@ -3177,8 +3180,7 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
bool host_tsc_clocksource, vcpus_matched;
lockdep_assert_held(&kvm->arch.tsc_write_lock);
- vcpus_matched = (ka->nr_vcpus_matched_tsc + 1 ==
- atomic_read(&kvm->online_vcpus));
+ vcpus_matched = ka->all_vcpus_matched_tsc;
/*
* If the host uses TSC clock, then passthrough TSC as stable
--
2.54.0
^ permalink raw reply related
* [PATCH v5 24/34] KVM: x86: Avoid gratuitous global clock updates
From: David Woodhouse @ 2026-06-08 14:48 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
Eliminate two sources of unnecessary KVM_REQ_GLOBAL_CLOCK_UPDATE:
1. kvm_write_system_time(): The global clock update was a workaround for
ever-drifting clocks based on the host's CLOCK_MONOTONIC subject to
NTP skew. Now that the KVM clock uses CLOCK_MONOTONIC_RAW, the clock
does not drift with NTP corrections and there is no need to
synchronize all vCPUs on boot or resume. Use KVM_REQ_CLOCK_UPDATE on
the vCPU itself, and only when the clock is being enabled, not
disabled.
2. kvm_arch_vcpu_load(): In master clock mode, migration between pCPUs
does not require any clock update since the master clock reference is
shared. Only request a local KVM_REQ_CLOCK_UPDATE for the vCPU's
first-ever load (vcpu->cpu == -1) to generate initial pvclock params.
In non-master-clock mode, keep the global update to synchronize all
vCPUs.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/kvm/x86.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 72fb4620a5ba..4fc21d701588 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2457,13 +2457,13 @@ static void kvm_write_system_time(struct kvm_vcpu *vcpu, gpa_t system_time,
}
vcpu->arch.time = system_time;
- kvm_make_request(KVM_REQ_GLOBAL_CLOCK_UPDATE, vcpu);
/* we verify if the enable bit is set... */
- if (system_time & 1)
+ if (system_time & 1) {
kvm_gpc_activate(&vcpu->arch.pv_time, system_time & ~1ULL,
sizeof(struct pvclock_vcpu_time_info));
- else
+ kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
+ } else
kvm_gpc_deactivate(&vcpu->arch.pv_time);
return;
@@ -5377,8 +5377,10 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
* On a host with synchronized TSC, there is no need to update
* kvmclock on vcpu->cpu migration
*/
- if (!vcpu->kvm->arch.use_master_clock || vcpu->cpu == -1)
+ if (!vcpu->kvm->arch.use_master_clock)
kvm_make_request(KVM_REQ_GLOBAL_CLOCK_UPDATE, vcpu);
+ else if (vcpu->cpu == -1)
+ kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
if (vcpu->cpu != cpu)
kvm_make_request(KVM_REQ_MIGRATE_TIMER, vcpu);
vcpu->cpu = cpu;
--
2.54.0
^ permalink raw reply related
* [PATCH v5 06/34] KVM: x86: Explicitly disable TSC scaling without CONSTANT_TSC
From: David Woodhouse @ 2026-06-08 14:47 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
KVM does make an attempt to cope with non-constant TSC, and has
notifiers to handle host TSC frequency changes. However, it *only*
adjusts the KVM clock, and doesn't adjust TSC frequency scaling when
the host changes.
This is presumably because non-constant TSCs were fixed in hardware
long before TSC scaling was implemented, so there should never be real
CPUs which have TSC scaling but *not* CONSTANT_TSC.
Such a combination could potentially happen in some odd L1 nesting
environment, but it isn't worth trying to support it. Just make the
dependency explicit.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
---
arch/x86/kvm/svm/svm.c | 3 ++-
arch/x86/kvm/vmx/vmx.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index e7fdd7a9c280..7817752533fe 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -5546,7 +5546,8 @@ static __init int svm_hardware_setup(void)
XFEATURE_MASK_BNDCSR);
if (tsc_scaling) {
- if (!boot_cpu_has(X86_FEATURE_TSCRATEMSR)) {
+ if (!boot_cpu_has(X86_FEATURE_TSCRATEMSR) ||
+ !boot_cpu_has(X86_FEATURE_CONSTANT_TSC)) {
tsc_scaling = false;
} else {
pr_info("TSC scaling supported\n");
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index a29896a9ef14..ed207cc7692d 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -8672,7 +8672,7 @@ __init int vmx_hardware_setup(void)
if (!enable_apicv || !cpu_has_vmx_ipiv())
enable_ipiv = false;
- if (cpu_has_vmx_tsc_scaling())
+ if (cpu_has_vmx_tsc_scaling() && boot_cpu_has(X86_FEATURE_CONSTANT_TSC))
kvm_caps.has_tsc_control = true;
kvm_caps.max_tsc_scaling_ratio = KVM_VMX_TSC_MULTIPLIER_MAX;
--
2.54.0
^ permalink raw reply related
* [PATCH v5 30/34] KVM: selftests: Add Xen runstate migration test
From: David Woodhouse @ 2026-06-08 14:48 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
Test that Xen runstate (steal time) is correctly accounted across a
simulated live migration using KVM_XEN_VCPU_ATTR and KVM_[GS]ET_CLOCK_GUEST.
The test simulates what a real VMM does during migration:
1. Creates a VM with Xen HVM config and runstate tracking
2. Runs the guest to accumulate some kvmclock time
3. Saves clock (KVM_GET_CLOCK_GUEST), TSC offset, and runstate
4. Marks the saved state as RUNSTATE_runnable (vCPU not running)
5. Destroys the source VM
6. Sleeps 10ms (simulating migration network transfer time)
7. Creates a new VM and restores all state precisely as saved
8. Runs the guest and verifies the migration gap appears as steal
The kernel accounts the gap because: on vcpu_load, it transitions from
RUNSTATE_runnable to RUNSTATE_running, computing delta = kvmclock_now -
state_entry_time. Since kvmclock has advanced past the saved entry time
(real time elapsed during migration), the delta is added to time_runnable.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
.../selftests/kvm/x86/xen_migration_test.c | 194 ++++++++++++++++++
1 file changed, 194 insertions(+)
create mode 100644 tools/testing/selftests/kvm/x86/xen_migration_test.c
diff --git a/tools/testing/selftests/kvm/x86/xen_migration_test.c b/tools/testing/selftests/kvm/x86/xen_migration_test.c
new file mode 100644
index 000000000000..37e8ace00611
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/xen_migration_test.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Test Xen runstate (steal time) preservation across simulated migration.
+ *
+ * Verifies that the kernel correctly accounts the migration gap as
+ * steal time (runnable) when runstate data is saved and restored
+ * precisely, but real time elapses during the migration.
+ *
+ * The key insight: userspace saves the runstate with state=RUNSTATE_runnable
+ * (the vCPU is not running during migration). On restore, the kernel sees
+ * that kvmclock has advanced past state_entry_time, and accounts the
+ * difference as time spent in the runnable state.
+ */
+#include <inttypes.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <string.h>
+#include <unistd.h>
+
+#include "test_util.h"
+#include "kvm_util.h"
+#include "processor.h"
+
+#include <asm/pvclock-abi.h>
+
+#define SHINFO_GPA 0xc0000000ULL
+#define RUNSTATE_GPA (SHINFO_GPA + 0x1000)
+
+#define RUNSTATE_running 0
+#define RUNSTATE_runnable 1
+#define RUNSTATE_blocked 2
+#define RUNSTATE_offline 3
+
+struct vcpu_runstate_info {
+ uint32_t state;
+ uint64_t state_entry_time;
+ uint64_t time[4];
+} __attribute__((packed));
+
+static void guest_code(void)
+{
+ volatile struct vcpu_runstate_info *rs =
+ (void *)(unsigned long)RUNSTATE_GPA;
+
+ /* Report runstate times — no need to enable kvmclock MSR,
+ * the kernel writes runstate using its internal kvmclock. */
+ GUEST_SYNC_ARGS(0, rs->time[RUNSTATE_runnable],
+ rs->time[RUNSTATE_running], 0, 0);
+}
+
+static struct kvm_vm *create_xen_vm(struct kvm_vcpu **vcpu)
+{
+ struct kvm_vm *vm;
+ int xen_caps;
+
+ vm = vm_create_with_one_vcpu(vcpu, guest_code);
+
+ xen_caps = kvm_check_cap(KVM_CAP_XEN_HVM);
+ TEST_REQUIRE(xen_caps & KVM_XEN_HVM_CONFIG_SHARED_INFO);
+ TEST_REQUIRE(xen_caps & KVM_XEN_HVM_CONFIG_RUNSTATE);
+
+ /* Map pages */
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS,
+ SHINFO_GPA, 1, 2, 0);
+ virt_map(vm, SHINFO_GPA, SHINFO_GPA, 2);
+
+ /* Enable Xen HVM with MSR interception (enables runstate tracking) */
+ struct kvm_xen_hvm_config cfg = {
+ .flags = KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL,
+ .msr = 0x40000000,
+ };
+ vm_ioctl(vm, KVM_XEN_HVM_CONFIG, &cfg);
+
+ /* Set shared_info */
+ struct kvm_xen_hvm_attr ha = {
+ .type = KVM_XEN_ATTR_TYPE_SHARED_INFO,
+ .u.shared_info.gfn = SHINFO_GPA >> 12,
+ };
+ vm_ioctl(vm, KVM_XEN_HVM_SET_ATTR, &ha);
+
+ /* Set runstate address */
+ struct kvm_xen_vcpu_attr rs_addr = {
+ .type = KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADDR,
+ .u.gpa = RUNSTATE_GPA,
+ };
+ vcpu_ioctl(*vcpu, KVM_XEN_VCPU_SET_ATTR, &rs_addr);
+
+ return vm;
+}
+
+int main(void)
+{
+ struct pvclock_vcpu_time_info pvti;
+ struct kvm_xen_vcpu_attr runstate_save;
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ struct ucall uc;
+ uint64_t tsc_offset;
+ int ret;
+
+ /* === SOURCE SIDE === */
+ pr_info("=== Source: create VM and run guest ===\n");
+ vm = create_xen_vm(&vcpu);
+
+ /* Run guest once to accumulate some runstate time */
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
+ TEST_ASSERT_EQ(get_ucall(vcpu, &uc), UCALL_SYNC);
+
+ pr_info(" Guest sees: runnable=%" PRIu64 " running=%" PRIu64 "\n",
+ uc.args[2], uc.args[3]);
+
+ /* Save clock state */
+ ret = __vcpu_ioctl(vcpu, KVM_GET_CLOCK_GUEST, &pvti);
+ TEST_ASSERT(!ret, "KVM_GET_CLOCK_GUEST failed");
+
+ /* Save TSC offset */
+ tsc_offset = vcpu_get_msr(vcpu, MSR_IA32_TSC_ADJUST);
+
+ /* Save runstate — the vCPU is now "runnable" (not running) */
+ runstate_save.type = KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_DATA;
+ vcpu_ioctl(vcpu, KVM_XEN_VCPU_GET_ATTR, &runstate_save);
+
+ /*
+ * Transition to runnable state before saving — the vCPU is
+ * not running during migration.
+ */
+ runstate_save.u.runstate.state = RUNSTATE_runnable;
+
+ pr_info(" Saved runstate: running=%" PRIu64 " runnable=%" PRIu64
+ " entry=%" PRIu64 "\n",
+ (uint64_t)runstate_save.u.runstate.time_running,
+ (uint64_t)runstate_save.u.runstate.time_runnable,
+ (uint64_t)runstate_save.u.runstate.state_entry_time);
+
+ uint64_t saved_runnable = runstate_save.u.runstate.time_runnable;
+
+ kvm_vm_release(vm);
+
+ /* === MIGRATION GAP === */
+ pr_info("=== Simulating migration (sleeping 10ms) ===\n");
+ usleep(10000);
+
+ /* === DESTINATION SIDE === */
+ pr_info("=== Destination: create new VM and restore ===\n");
+ vm = create_xen_vm(&vcpu);
+
+ /* Restore TSC offset */
+ vcpu_set_msr(vcpu, MSR_IA32_TSC_ADJUST, tsc_offset);
+
+ /* Restore clock — kvmclock will now be ~10ms ahead of the snapshot */
+ vcpu_ioctl(vcpu, KVM_SET_CLOCK_GUEST, &pvti);
+
+ /* Restore runstate exactly as saved (state=runnable) */
+ runstate_save.type = KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_DATA;
+ ret = __vcpu_ioctl(vcpu, KVM_XEN_VCPU_SET_ATTR, &runstate_save);
+ TEST_ASSERT(!ret, "Restore runstate failed: errno %d", errno);
+
+ /*
+ * Run the guest. When the vCPU enters vcpu_run, the kernel
+ * transitions from RUNSTATE_runnable to RUNSTATE_running.
+ * It computes: delta = kvmclock_now - state_entry_time
+ * This delta (which includes the migration gap) is added to
+ * time_runnable (steal time).
+ */
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
+ TEST_ASSERT_EQ(get_ucall(vcpu, &uc), UCALL_SYNC);
+
+ uint64_t guest_runnable = uc.args[2];
+ uint64_t guest_running = uc.args[3];
+
+ pr_info(" Guest sees: runnable=%" PRIu64 " running=%" PRIu64 "\n",
+ guest_runnable, guest_running);
+
+ uint64_t steal_increase = guest_runnable - saved_runnable;
+ pr_info(" Steal time increase: %" PRIu64 " ns (migration gap)\n",
+ steal_increase);
+
+ /*
+ * The steal time increase should be at least 10ms (the sleep)
+ * but not more than 5s (allowing for VM creation overhead).
+ * The actual gap is from the source's state_entry_time to the
+ * destination's kvmclock "now" at vcpu_load time.
+ */
+ TEST_ASSERT(steal_increase >= 10000000ULL &&
+ steal_increase < 5000000000ULL,
+ "Steal time increase %" PRIu64 " ns not in expected range "
+ "[10ms, 5s]", steal_increase);
+
+ kvm_vm_release(vm);
+ pr_info("PASS: Migration gap correctly accounted as steal time\n");
+ return 0;
+}
--
2.54.0
^ permalink raw reply related
* [PATCH v5 08/34] KVM: x86: Add KVM_VCPU_TSC_SCALE and fix the documentation on TSC migration
From: David Woodhouse @ 2026-06-08 14:47 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
The documentation on TSC migration using KVM_VCPU_TSC_OFFSET is woefully
inadequate. It ignores TSC scaling, and ignores the fact that the host
TSC may differ from one host to the next (and in fact because of the way
the kernel calibrates it, it generally differs from one boot to the next
even on the same hardware).
Add KVM_VCPU_TSC_SCALE to extract the actual scale ratio and frac_bits,
and attempt to document the process that userspace needs to follow to
preserve the TSC across migration. Add a self test to function as an
exemplar.
Only enumerate KVM_VCPU_TSC_SCALE when kvm_caps.has_tsc_control is true,
since the scaling ratio is only meaningful when hardware TSC scaling is
supported.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
---
Documentation/virt/kvm/devices/vcpu.rst | 119 ++++--
arch/x86/include/uapi/asm/kvm.h | 6 +
arch/x86/kvm/x86.c | 22 +
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../kvm/x86/pvclock_migration_test.c | 382 ++++++++++++++++++
5 files changed, 500 insertions(+), 30 deletions(-)
create mode 100644 tools/testing/selftests/kvm/x86/pvclock_migration_test.c
diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst
index 5e3805820010..167aa4140d30 100644
--- a/Documentation/virt/kvm/devices/vcpu.rst
+++ b/Documentation/virt/kvm/devices/vcpu.rst
@@ -243,7 +243,10 @@ Returns:
Specifies the guest's TSC offset relative to the host's TSC. The guest's
TSC is then derived by the following equation:
- guest_tsc = host_tsc + KVM_VCPU_TSC_OFFSET
+ guest_tsc = ((host_tsc * tsc_scale_ratio) >> tsc_scale_bits) + KVM_VCPU_TSC_OFFSET
+
+The values of tsc_scale_ratio and tsc_scale_bits can be obtained using
+the KVM_VCPU_TSC_SCALE attribute.
This attribute is useful to adjust the guest's TSC on live migration,
so that the TSC counts the time during which the VM was paused. The
@@ -251,44 +254,100 @@ following describes a possible algorithm to use for this purpose.
From the source VMM process:
-1. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (tsc_src),
+1. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (host_tsc_src),
kvmclock nanoseconds (guest_src), and host CLOCK_REALTIME nanoseconds
- (host_src).
+ (time_src) at a given moment (Tsrc).
+
+2. For each vCPU[i]:
+
+ a. Read the KVM_VCPU_TSC_OFFSET attribute to record the guest TSC offset
+ (ofs_src[i]).
-2. Read the KVM_VCPU_TSC_OFFSET attribute for every vCPU to record the
- guest TSC offset (ofs_src[i]).
+ b. Read the KVM_VCPU_TSC_SCALE attribute to record the guest TSC scaling
+ ratio (ratio_src[i], frac_bits_src[i]).
-3. Invoke the KVM_GET_TSC_KHZ ioctl to record the frequency of the
- guest's TSC (freq).
+ c. Use host_tsc_src and the scaling/offset factors to calculate this
+ vCPU's TSC at time Tsrc:
+
+ tsc_src[i] = ((host_tsc_src * ratio_src[i]) >> frac_bits_src[i]) + ofs_src[i]
+
+3. Invoke the KVM_GET_CLOCK_GUEST ioctl on the boot vCPU to return the KVM
+ clock as a function of the guest TSC (pvti_src). (This ioctl may not
+ succeed if the host and guest TSCs are not consistent and well-behaved.)
From the destination VMM process:
-4. Invoke the KVM_SET_CLOCK ioctl, providing the source nanoseconds from
- kvmclock (guest_src) and CLOCK_REALTIME (host_src) in their respective
- fields. Ensure that the KVM_CLOCK_REALTIME flag is set in the provided
- structure.
+4. Before creating the vCPUs, invoke the KVM_SET_TSC_KHZ ioctl on the VM, to
+ set the scaled frequency of the guest's TSC (freq).
+
+5. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (host_tsc_dst) and
+ host CLOCK_REALTIME nanoseconds (time_dst) at a given moment (Tdst).
+
+6. Calculate the number of nanoseconds elapsed between Tsrc and Tdst:
+
+ ΔT = time_dst - time_src
+
+7. As each vCPU[i] is created:
+
+ a. Read the KVM_VCPU_TSC_SCALE attribute to record the guest TSC scaling
+ ratio (ratio_dst[i], frac_bits_dst[i]).
+
+ b. Calculate the intended guest TSC value at time Tdst:
+
+ tsc_dst[i] = tsc_src[i] + (ΔT * freq[i])
- KVM will advance the VM's kvmclock to account for elapsed time since
- recording the clock values. Note that this will cause problems in
- the guest (e.g., timeouts) unless CLOCK_REALTIME is synchronized
- between the source and destination, and a reasonably short time passes
- between the source pausing the VMs and the destination executing
- steps 4-7.
+ c. Use host_tsc_dst and the scaling factors to calculate this vCPU's
+ raw scaled TSC at time Tdst without offsetting:
+
+ raw_dst[i] = ((host_tsc_dst * ratio_dst[i]) >> frac_bits_dst[i])
+
+ d. Calculate ofs_dst[i] = tsc_dst[i] - raw_dst[i] and set the resulting
+ offset using the KVM_VCPU_TSC_OFFSET attribute.
+
+8. If pvti_src was provided, invoke the KVM_SET_CLOCK_GUEST ioctl on the boot
+ vCPU to restore the KVM clock as a precise function of the guest TSC.
+
+9. If KVM_SET_CLOCK_GUEST was not available or failed (e.g. because the
+ master clock is not active), fall back to the KVM_SET_CLOCK ioctl,
+ providing the source nanoseconds from kvmclock (guest_src) and
+ CLOCK_REALTIME (time_src) in their respective fields. Ensure that the
+ KVM_CLOCK_REALTIME flag is set in the provided structure.
+
+ KVM will restore the VM's kvmclock, accounting for elapsed time since
+ the clock values were recorded. Note that this will cause problems in
+ the guest (e.g., timeouts) unless CLOCK_REALTIME is synchronized between
+ the source and destination, and a reasonably short time passes between
+ the source pausing the VMs and the destination resuming them.
+ Due to the KVM_[SG]ET_CLOCK API using CLOCK_REALTIME instead of
+ CLOCK_TAI, leap seconds during the migration may also introduce errors.
+
+4.2 ATTRIBUTE: KVM_VCPU_TSC_SCALE
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+:Parameters: struct kvm_vcpu_tsc_scale
+
+Returns:
+
+ ======= ======================================
+ -EFAULT Error reading the provided parameter
+ address.
+ -ENXIO Attribute not supported (no TSC scaling)
+ -EINVAL Invalid request to write the attribute
+ ======= ======================================
-5. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (tsc_dest) and
- kvmclock nanoseconds (guest_dest).
+This read-only attribute reports the guest's TSC scaling factor, in the form
+of a fixed-point number represented by the following structure::
-6. Adjust the guest TSC offsets for every vCPU to account for (1) time
- elapsed since recording state and (2) difference in TSCs between the
- source and destination machine:
+ struct kvm_vcpu_tsc_scale {
+ __u64 tsc_ratio;
+ __u64 tsc_frac_bits;
+ };
- ofs_dst[i] = ofs_src[i] -
- (guest_src - guest_dest) * freq +
- (tsc_src - tsc_dest)
+The tsc_frac_bits field indicates the location of the fixed point, such that
+host TSC values are converted to guest TSC using the formula:
- ("ofs[i] + tsc - guest * freq" is the guest TSC value corresponding to
- a time of 0 in kvmclock. The above formula ensures that it is the
- same on the destination as it was on the source).
+ guest_tsc = ((host_tsc * tsc_ratio) >> tsc_frac_bits) + offset
-7. Write the KVM_VCPU_TSC_OFFSET attribute for every vCPU with the
- respective value derived in the previous step.
+Userspace can use this to precisely calculate the guest TSC from the host
+TSC at any given moment. This is needed for accurate migration of guests,
+as described in the documentation for the KVM_VCPU_TSC_OFFSET attribute.
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 5f2b30d0405c..384be9a53395 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -961,6 +961,12 @@ struct kvm_hyperv_eventfd {
/* for KVM_{GET,SET,HAS}_DEVICE_ATTR */
#define KVM_VCPU_TSC_CTRL 0 /* control group for the timestamp counter (TSC) */
#define KVM_VCPU_TSC_OFFSET 0 /* attribute for the TSC offset */
+#define KVM_VCPU_TSC_SCALE 1 /* attribute for TSC scaling factor */
+
+struct kvm_vcpu_tsc_scale {
+ __u64 tsc_ratio;
+ __u64 tsc_frac_bits;
+};
/* x86-specific KVM_EXIT_HYPERCALL flags. */
#define KVM_EXIT_HYPERCALL_LONG_MODE _BITULL(0)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c1897d939da9..6337f9b9d7ac 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5930,6 +5930,9 @@ static int kvm_arch_tsc_has_attr(struct kvm_vcpu *vcpu,
case KVM_VCPU_TSC_OFFSET:
r = 0;
break;
+ case KVM_VCPU_TSC_SCALE:
+ r = kvm_caps.has_tsc_control ? 0 : -ENXIO;
+ break;
default:
r = -ENXIO;
}
@@ -5950,6 +5953,22 @@ static int kvm_arch_tsc_get_attr(struct kvm_vcpu *vcpu,
break;
r = 0;
break;
+ case KVM_VCPU_TSC_SCALE: {
+ struct kvm_vcpu_tsc_scale scale;
+
+ if (!kvm_caps.has_tsc_control) {
+ r = -ENXIO;
+ break;
+ }
+
+ scale.tsc_ratio = vcpu->arch.l1_tsc_scaling_ratio;
+ scale.tsc_frac_bits = kvm_caps.tsc_scaling_ratio_frac_bits;
+ r = -EFAULT;
+ if (copy_to_user(uaddr, &scale, sizeof(scale)))
+ break;
+ r = 0;
+ break;
+ }
default:
r = -ENXIO;
}
@@ -5989,6 +6008,9 @@ static int kvm_arch_tsc_set_attr(struct kvm_vcpu *vcpu,
r = 0;
break;
}
+ case KVM_VCPU_TSC_SCALE:
+ r = -EINVAL; /* Read only */
+ break;
default:
r = -ENXIO;
}
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index fb935ae3bf38..90568ab631d7 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -106,6 +106,7 @@ TEST_GEN_PROGS_x86 += x86/pmu_event_filter_test
TEST_GEN_PROGS_x86 += x86/private_mem_conversions_test
TEST_GEN_PROGS_x86 += x86/private_mem_kvm_exits_test
TEST_GEN_PROGS_x86 += x86/pvclock_test
+TEST_GEN_PROGS_x86 += x86/pvclock_migration_test
TEST_GEN_PROGS_x86 += x86/set_boot_cpu_id
TEST_GEN_PROGS_x86 += x86/set_sregs_test
TEST_GEN_PROGS_x86 += x86/smaller_maxphyaddr_emulation_test
diff --git a/tools/testing/selftests/kvm/x86/pvclock_migration_test.c b/tools/testing/selftests/kvm/x86/pvclock_migration_test.c
new file mode 100644
index 000000000000..6a7eaf627d1a
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/pvclock_migration_test.c
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Test KVM clock precision across simulated live migration.
+ *
+ * Verifies that the documented TSC migration procedure (using
+ * KVM_VCPU_TSC_OFFSET, KVM_VCPU_TSC_SCALE, KVM_GET_CLOCK, and
+ * KVM_SET_CLOCK_GUEST) preserves the kvmclock's relationship to
+ * CLOCK_MONOTONIC_RAW.
+ *
+ * The test:
+ * 1. Creates a VM, runs the guest to enable kvmclock
+ * 2. Does a PTP-like ABA measurement of kvmclock vs CLOCK_MONOTONIC_RAW
+ * 3. Follows the documented migration procedure (same host, 1s pause)
+ * 4. Does the same ABA measurement on the destination VM
+ * 5. Verifies the kvmclock-vs-monotonic delta is preserved
+ */
+#include <inttypes.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <string.h>
+#include <time.h>
+#include <unistd.h>
+
+#include "test_util.h"
+#include "kvm_util.h"
+#include "processor.h"
+
+#include <asm/pvclock-abi.h>
+
+#define KVMCLOCK_GPA 0xc0000000ULL
+
+static void guest_code(void)
+{
+ wrmsr(MSR_KVM_SYSTEM_TIME_NEW, KVMCLOCK_GPA | 1);
+ GUEST_SYNC(0);
+ GUEST_SYNC(1);
+}
+
+static uint64_t read_kvmclock_ns(struct kvm_vm *vm)
+{
+ struct kvm_clock_data data = {};
+
+ vm_ioctl(vm, KVM_GET_CLOCK, &data);
+ return data.clock;
+}
+
+static uint64_t pvclock_read_cycles(struct pvclock_vcpu_time_info *src,
+ uint64_t tsc)
+{
+ uint64_t delta = tsc - src->tsc_timestamp;
+ uint64_t ns;
+
+ if (src->tsc_shift >= 0)
+ delta <<= src->tsc_shift;
+ else
+ delta >>= -(int32_t)src->tsc_shift;
+
+ ns = (unsigned __int128)delta * src->tsc_to_system_mul >> 32;
+ return src->system_time + ns;
+}
+
+/*
+ * ABA measurement: read CLOCK_MONOTONIC_RAW, kvmclock, CLOCK_MONOTONIC_RAW.
+ * Repeat 3 times, keep the reading with the smallest spread.
+ */
+static void aba_reading(struct kvm_vm *vm, uint64_t *lo, uint64_t *kvm_ns,
+ uint64_t *hi)
+{
+ uint64_t best_spread = UINT64_MAX;
+ int i;
+
+ for (i = 0; i < 3; i++) {
+ struct timespec ts1, ts2;
+ uint64_t m1, m2, clk;
+
+ clock_gettime(CLOCK_MONOTONIC_RAW, &ts1);
+ clk = read_kvmclock_ns(vm);
+ clock_gettime(CLOCK_MONOTONIC_RAW, &ts2);
+
+ m1 = ts1.tv_sec * 1000000000ULL + ts1.tv_nsec;
+ m2 = ts2.tv_sec * 1000000000ULL + ts2.tv_nsec;
+
+ if (m2 - m1 < best_spread) {
+ best_spread = m2 - m1;
+ *lo = m1;
+ *kvm_ns = clk;
+ *hi = m2;
+ }
+ }
+}
+
+static struct kvm_vm *create_vm(struct kvm_vcpu **vcpu)
+{
+ struct kvm_vm *vm = vm_create_with_one_vcpu(vcpu, guest_code);
+
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS,
+ KVMCLOCK_GPA, 1, 1, 0);
+ virt_map(vm, KVMCLOCK_GPA, KVMCLOCK_GPA, 1);
+ return vm;
+}
+
+int main(void)
+{
+ struct pvclock_vcpu_time_info pvti_src;
+ struct kvm_clock_data clock_src, clock_dst;
+ struct kvm_vcpu_tsc_scale scale_src, scale_dst;
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ struct ucall uc;
+ uint64_t mono_before, kvm_before, kvm_after;
+ int64_t delta_before;
+ uint64_t ofs_src, tsc_src, tsc_dst, raw_dst, ofs_dst;
+ uint64_t host_tsc_src, host_tsc_dst;
+ uint64_t time_src, time_dst;
+ int64_t delta_t;
+ uint32_t freq_khz = 1500000; /* 1.5 GHz — forces TSC scaling */
+ int ret;
+
+ TEST_REQUIRE(sys_clocksource_is_based_on_tsc());
+
+ /* === SOURCE SIDE === */
+ pr_info("=== Source VM ===\n");
+ vm = create_vm(&vcpu);
+
+ /* Set guest TSC frequency (may trigger scaling) */
+ vcpu_ioctl(vcpu, KVM_SET_TSC_KHZ, (void *)(unsigned long)freq_khz);
+
+ /* Run guest to enable kvmclock */
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
+ TEST_ASSERT_EQ(get_ucall(vcpu, &uc), UCALL_SYNC);
+
+ /* ABA measurement: kvmclock vs CLOCK_MONOTONIC_RAW */
+ uint64_t src_mono_lo, src_mono_hi;
+ aba_reading(vm, &src_mono_lo, &kvm_before, &src_mono_hi);
+ mono_before = (src_mono_lo + src_mono_hi) / 2;
+ delta_before = (int64_t)(kvm_before - mono_before);
+ pr_info(" kvmclock - MONOTONIC_RAW = %" PRId64 " ns (±%" PRIu64 " ns)\n",
+ delta_before, (src_mono_hi - src_mono_lo) / 2);
+
+ /* Step 1: KVM_GET_CLOCK for atomic {host_tsc, realtime} */
+ memset(&clock_src, 0, sizeof(clock_src));
+ clock_src.flags = KVM_CLOCK_REALTIME;
+ vm_ioctl(vm, KVM_GET_CLOCK, &clock_src);
+ host_tsc_src = clock_src.host_tsc;
+ time_src = clock_src.realtime;
+
+ /* Step 2: Save TSC offset and scale */
+ {
+ struct kvm_device_attr attr = {
+ .group = KVM_VCPU_TSC_CTRL,
+ .attr = KVM_VCPU_TSC_OFFSET,
+ .addr = (uint64_t)(uintptr_t)&ofs_src,
+ };
+ vcpu_ioctl(vcpu, KVM_GET_DEVICE_ATTR, &attr);
+ }
+ {
+ struct kvm_device_attr attr = {
+ .group = KVM_VCPU_TSC_CTRL,
+ .attr = KVM_VCPU_TSC_SCALE,
+ .addr = (uint64_t)(uintptr_t)&scale_src,
+ };
+ memset(&scale_src, 0, sizeof(scale_src));
+ __vcpu_ioctl(vcpu, KVM_GET_DEVICE_ATTR, &attr);
+ }
+
+ /* Compute guest TSC at Tsrc */
+ if (scale_src.tsc_frac_bits)
+ tsc_src = ((unsigned __int128)host_tsc_src * scale_src.tsc_ratio
+ >> scale_src.tsc_frac_bits) + ofs_src;
+ else
+ tsc_src = host_tsc_src + ofs_src;
+
+ /* Step 3: KVM_GET_CLOCK_GUEST */
+ ret = __vcpu_ioctl(vcpu, KVM_GET_CLOCK_GUEST, &pvti_src);
+ TEST_ASSERT(!ret, "KVM_GET_CLOCK_GUEST failed");
+
+ pr_info(" TSC freq=%u kHz, offset=%" PRId64 "\n", freq_khz, (int64_t)ofs_src);
+
+ kvm_vm_release(vm);
+
+ /* === PAUSE (simulate migration) === */
+ pr_info("=== Pausing 1 second ===\n");
+ sleep(1);
+
+ /* === DESTINATION SIDE === */
+ pr_info("=== Destination VM ===\n");
+ vm = create_vm(&vcpu);
+
+ /* Step 4: KVM_SET_TSC_KHZ */
+ vcpu_ioctl(vcpu, KVM_SET_TSC_KHZ, (void *)(unsigned long)freq_khz);
+
+ /* Step 5: KVM_GET_CLOCK for atomic {host_tsc, realtime} pair.
+ * Master clock is active from vCPU creation.
+ */
+ memset(&clock_dst, 0, sizeof(clock_dst));
+ vm_ioctl(vm, KVM_GET_CLOCK, &clock_dst);
+ host_tsc_dst = clock_dst.host_tsc;
+ time_dst = clock_dst.realtime;
+
+ /* Step 6: ΔT */
+ delta_t = (int64_t)(time_dst - time_src);
+
+ /* Step 7: Compute destination offset */
+ {
+ struct kvm_device_attr attr = {
+ .group = KVM_VCPU_TSC_CTRL,
+ .attr = KVM_VCPU_TSC_SCALE,
+ .addr = (uint64_t)(uintptr_t)&scale_dst,
+ };
+ memset(&scale_dst, 0, sizeof(scale_dst));
+ __vcpu_ioctl(vcpu, KVM_GET_DEVICE_ATTR, &attr);
+ }
+
+ tsc_dst = tsc_src + (uint64_t)((int64_t)freq_khz * 1000 * delta_t / 1000000000LL);
+
+ if (scale_dst.tsc_frac_bits)
+ raw_dst = (unsigned __int128)host_tsc_dst * scale_dst.tsc_ratio
+ >> scale_dst.tsc_frac_bits;
+ else
+ raw_dst = host_tsc_dst;
+
+ ofs_dst = tsc_dst - raw_dst;
+
+ /*
+ * The TSC offset delta introduced by using CLOCK_REALTIME to
+ * estimate elapsed time. On same host, the correct offset is
+ * ofs_src; the difference is the CLOCK_REALTIME-vs-TSC error.
+ */
+ int64_t tsc_ofs_delta = (int64_t)(ofs_dst - ofs_src);
+ int64_t tsc_ofs_delta_ns = tsc_ofs_delta * 1000000000LL / ((int64_t)freq_khz * 1000);
+ pr_info(" Destination TSC offset=%" PRId64
+ ", imprecision from CLOCK_REALTIME: %" PRId64 " cycles = %"
+ PRId64 " ns\n", (int64_t)ofs_dst, tsc_ofs_delta, tsc_ofs_delta_ns);
+
+ /* Set TSC offset */
+ {
+ struct kvm_device_attr attr = {
+ .group = KVM_VCPU_TSC_CTRL,
+ .attr = KVM_VCPU_TSC_OFFSET,
+ .addr = (uint64_t)(uintptr_t)&ofs_dst,
+ };
+ vcpu_ioctl(vcpu, KVM_SET_DEVICE_ATTR, &attr);
+ }
+
+ /* Step 8: KVM_SET_CLOCK_GUEST */
+ ret = __vcpu_ioctl(vcpu, KVM_SET_CLOCK_GUEST, &pvti_src);
+ TEST_ASSERT(!ret, "KVM_SET_CLOCK_GUEST failed: errno %d", errno);
+
+ /* Run guest to update pvclock page on destination */
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
+ TEST_ASSERT_EQ(get_ucall(vcpu, &uc), UCALL_SYNC);
+
+ /* ABA measurement on destination */
+ uint64_t mono_lo, mono_hi;
+ aba_reading(vm, &mono_lo, &kvm_after, &mono_hi);
+
+ /*
+ * The kvmclock is tied to the guest TSC via SET_CLOCK_GUEST.
+ * The guest TSC is offset from the correct value by tsc_ofs_delta_ns
+ * (due to CLOCK_REALTIME imprecision). So the kvmclock should be
+ * offset from CLOCK_MONOTONIC_RAW by exactly:
+ * (original delta) + tsc_ofs_delta_ns
+ *
+ * The "original delta" has uncertainty from the source ABA spread,
+ * and the measurement has uncertainty from the destination ABA spread.
+ * Verify the expected value falls within the combined bounds.
+ */
+ int64_t delta_before_lo = (int64_t)(kvm_before - src_mono_hi);
+ int64_t delta_before_hi = (int64_t)(kvm_before - src_mono_lo);
+ int64_t expected_lo = delta_before_lo + tsc_ofs_delta_ns;
+ int64_t expected_hi = delta_before_hi + tsc_ofs_delta_ns;
+ int64_t actual_lo = (int64_t)(kvm_after - mono_hi);
+ int64_t actual_hi = (int64_t)(kvm_after - mono_lo);
+
+ /* Show the shift relative to the source measurement */
+ int64_t expected_mid = tsc_ofs_delta_ns;
+ int64_t expected_err = (int64_t)(src_mono_hi - src_mono_lo) / 2;
+ int64_t actual_mid = ((actual_lo + actual_hi) / 2) - delta_before;
+ int64_t actual_err = (int64_t)(mono_hi - mono_lo) / 2;
+ pr_info(" kvmclock-mono shift: expected %" PRId64 " ns (±%" PRId64
+ "), measured %" PRId64 " ns (±%" PRId64 ")\n",
+ expected_mid, expected_err, actual_mid, actual_err);
+
+ /* The ranges must overlap */
+ TEST_ASSERT(expected_hi >= actual_lo && expected_lo <= actual_hi,
+ "Ranges don't overlap: expected [%" PRId64 ", %" PRId64
+ "] measured [%" PRId64 ", %" PRId64 "]",
+ expected_lo, expected_hi, actual_lo, actual_hi);
+
+ /*
+ * Direct pvclock verification: read the destination pvclock page
+ * and verify that computing kvmclock from pvti_src and pvti_dst
+ * at the same guest TSC gives the same result.
+ *
+ * Get an atomic {host_tsc, kvmclock} pair, scale host_tsc to
+ * guest TSC using KVM_VCPU_TSC_SCALE, then compute kvmclock
+ * from both pvclock structs.
+ */
+ struct kvm_clock_data clock_now = {};
+ vm_ioctl(vm, KVM_GET_CLOCK, &clock_now);
+
+ struct pvclock_vcpu_time_info *pvti_dst = addr_gpa2hva(vm, KVMCLOCK_GPA);
+ uint64_t host_tsc_now = clock_now.host_tsc;
+ uint64_t guest_tsc_now;
+
+ if (scale_dst.tsc_frac_bits)
+ guest_tsc_now = ((unsigned __int128)host_tsc_now *
+ scale_dst.tsc_ratio >> scale_dst.tsc_frac_bits)
+ + ofs_dst;
+ else
+ guest_tsc_now = host_tsc_now + ofs_dst;
+
+ uint64_t clk_from_src = pvclock_read_cycles(&pvti_src, guest_tsc_now);
+ uint64_t clk_from_dst = pvclock_read_cycles(pvti_dst, guest_tsc_now);
+ int64_t pvclock_delta = (int64_t)(clk_from_src - clk_from_dst);
+
+ pr_info(" Pvclock direct: src=%" PRIu64 " dst=%" PRIu64
+ " delta=%" PRId64 " ns\n", clk_from_src, clk_from_dst, pvclock_delta);
+ pr_info(" KVM_GET_CLOCK: %" PRIu64 " ns\n", (uint64_t)clock_now.clock);
+
+ TEST_ASSERT(pvclock_delta >= -1 && pvclock_delta <= 1,
+ "pvclock src vs dst disagree by %" PRId64 " ns", pvclock_delta);
+
+ /*
+ * Tight ABA: compare pvclock_read() directly (no ioctl) against
+ * CLOCK_MONOTONIC_RAW. The spread should be much smaller since
+ * there's no syscall between the two clock_gettime calls — just
+ * rdtsc + userspace mul/shift.
+ */
+ uint64_t tight_mono_lo = 0, tight_mono_hi = 0, tight_kvm = 0;
+ uint64_t tight_best_spread = UINT64_MAX;
+ for (int i = 0; i < 3; i++) {
+ struct timespec ts1, ts2;
+ uint64_t m1, m2, tsc, clk;
+
+ clock_gettime(CLOCK_MONOTONIC_RAW, &ts1);
+ tsc = rdtsc();
+ clock_gettime(CLOCK_MONOTONIC_RAW, &ts2);
+
+ m1 = ts1.tv_sec * 1000000000ULL + ts1.tv_nsec;
+ m2 = ts2.tv_sec * 1000000000ULL + ts2.tv_nsec;
+
+ /* Scale host TSC to guest TSC */
+ if (scale_dst.tsc_frac_bits)
+ tsc = ((unsigned __int128)tsc * scale_dst.tsc_ratio
+ >> scale_dst.tsc_frac_bits) + ofs_dst;
+ else
+ tsc += ofs_dst;
+
+ clk = pvclock_read_cycles(pvti_dst, tsc);
+
+ if (m2 - m1 < tight_best_spread) {
+ tight_best_spread = m2 - m1;
+ tight_mono_lo = m1;
+ tight_mono_hi = m2;
+ tight_kvm = clk;
+ }
+ }
+ pr_info(" Tight ABA spread: %" PRIu64 " ns (best of 3)\n", tight_best_spread);
+
+ int64_t tight_expected_lo = delta_before_lo + tsc_ofs_delta_ns;
+ int64_t tight_expected_hi = delta_before_hi + tsc_ofs_delta_ns;
+ int64_t tight_actual_lo = (int64_t)(tight_kvm - tight_mono_hi);
+ int64_t tight_actual_hi = (int64_t)(tight_kvm - tight_mono_lo);
+ int64_t tight_actual_mid = ((tight_actual_lo + tight_actual_hi) / 2) - delta_before;
+ int64_t tight_actual_err = (int64_t)(tight_mono_hi - tight_mono_lo) / 2;
+
+ pr_info(" Tight kvmclock-mono shift: expected %" PRId64
+ " ns (±%" PRId64 "), measured %" PRId64 " ns (±%" PRId64 ")\n",
+ expected_mid, expected_err, tight_actual_mid, tight_actual_err);
+
+ TEST_ASSERT(tight_expected_hi >= tight_actual_lo &&
+ tight_expected_lo <= tight_actual_hi,
+ "Tight ABA ranges don't overlap");
+
+ kvm_vm_release(vm);
+ pr_info("PASS: kvmclock offset matches TSC delta from CLOCK_REALTIME"
+ " (%" PRId64 " ns) within ABA bounds\n", tsc_ofs_delta_ns);
+ return 0;
+}
--
2.54.0
^ permalink raw reply related
* [PATCH v5 22/34] KVM: selftests: Add master clock offset test
From: David Woodhouse @ 2026-06-08 14:48 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
Verify that KVM master clock mode remains active when vCPUs have
different TSC offsets but the same frequency. Creates three vCPUs,
sets one to a different TSC value, and confirms:
- KVM_CLOCK_HOST_TSC is set (master clock active)
- KVM_CLOCK_TSC_STABLE is NOT set (offsets differ)
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Assisted-by: Kiro (claude-opus-4.6-1m)
---
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../kvm/x86/masterclock_offset_test.c | 180 ++++++++++++++++++
2 files changed, 181 insertions(+)
create mode 100644 tools/testing/selftests/kvm/x86/masterclock_offset_test.c
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 90568ab631d7..7ecaaf82056e 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -106,6 +106,7 @@ TEST_GEN_PROGS_x86 += x86/pmu_event_filter_test
TEST_GEN_PROGS_x86 += x86/private_mem_conversions_test
TEST_GEN_PROGS_x86 += x86/private_mem_kvm_exits_test
TEST_GEN_PROGS_x86 += x86/pvclock_test
+TEST_GEN_PROGS_x86 += x86/masterclock_offset_test
TEST_GEN_PROGS_x86 += x86/pvclock_migration_test
TEST_GEN_PROGS_x86 += x86/set_boot_cpu_id
TEST_GEN_PROGS_x86 += x86/set_sregs_test
diff --git a/tools/testing/selftests/kvm/x86/masterclock_offset_test.c b/tools/testing/selftests/kvm/x86/masterclock_offset_test.c
new file mode 100644
index 000000000000..88e2bd2edab5
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/masterclock_offset_test.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Test that KVM master clock mode works with different TSC offsets
+ * as long as all vCPUs have the same TSC frequency.
+ */
+#include <stdint.h>
+#include <string.h>
+
+#include "test_util.h"
+#include "kvm_util.h"
+#include "processor.h"
+
+#include <asm/pvclock-abi.h>
+
+#define KVMCLOCK_GPA 0xc0000000ull
+#define TSC_OFFSET (1000000000ULL)
+
+static uint64_t pvclock_calc(struct pvclock_vcpu_time_info *pvti, uint64_t guest_tsc)
+{
+ uint64_t delta = guest_tsc - pvti->tsc_timestamp;
+
+ if (pvti->tsc_shift >= 0)
+ delta <<= pvti->tsc_shift;
+ else
+ delta >>= -(int)pvti->tsc_shift;
+
+ return pvti->system_time + ((__uint128_t)delta * pvti->tsc_to_system_mul >> 32);
+}
+
+static void guest_code(void)
+{
+ wrmsr(MSR_KVM_SYSTEM_TIME_NEW, KVMCLOCK_GPA | KVM_MSR_ENABLED);
+ for (;;)
+ GUEST_SYNC(0);
+}
+
+int main(void)
+{
+ struct kvm_vcpu *vcpus[3];
+ struct kvm_clock_data clock;
+ struct pvclock_vcpu_time_info pvti[3];
+ struct kvm_vm *vm;
+ uint64_t offset0, host_tsc, clk0, clk2;
+ int i;
+
+ TEST_REQUIRE(sys_clocksource_is_based_on_tsc());
+
+ vm = vm_create_with_vcpus(3, guest_code, vcpus);
+
+ TEST_REQUIRE(!__vcpu_has_device_attr(vcpus[0], KVM_VCPU_TSC_CTRL,
+ KVM_VCPU_TSC_OFFSET));
+
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS,
+ KVMCLOCK_GPA, 1,
+ vm_calc_num_guest_pages(VM_MODE_DEFAULT,
+ getpagesize()), 0);
+ virt_map(vm, KVMCLOCK_GPA, KVMCLOCK_GPA,
+ vm_calc_num_guest_pages(VM_MODE_DEFAULT, getpagesize()));
+
+ /* Get vCPU 0's default offset and set vCPU 2's offset higher */
+ vcpu_device_attr_get(vcpus[0], KVM_VCPU_TSC_CTRL,
+ KVM_VCPU_TSC_OFFSET, &offset0);
+ uint64_t offset2 = offset0 + TSC_OFFSET;
+ vcpu_device_attr_set(vcpus[2], KVM_VCPU_TSC_CTRL,
+ KVM_VCPU_TSC_OFFSET, &offset2);
+
+ /* Run each vCPU to enable kvmclock (with offset already set) */
+ for (i = 0; i < 3; i++) {
+ vcpu_run(vcpus[i]);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpus[i], KVM_EXIT_IO);
+ }
+
+ /* Check master clock is active */
+ memset(&clock, 0, sizeof(clock));
+ vm_ioctl(vm, KVM_GET_CLOCK, &clock);
+ pr_info("KVM_GET_CLOCK flags: 0x%x\n", clock.flags);
+ TEST_ASSERT(clock.flags & KVM_CLOCK_HOST_TSC,
+ "Master clock should be active, flags=0x%x", clock.flags);
+ TEST_ASSERT(clock.flags & KVM_CLOCK_TSC_STABLE,
+ "KVM_CLOCK_TSC_STABLE should be set, flags=0x%x", clock.flags);
+
+ /* Get per-vCPU pvclock in order 0, 2, 1 */
+ int order[] = {0, 2, 1};
+ for (i = 0; i < 3; i++) {
+ int idx = order[i];
+ __vcpu_ioctl(vcpus[idx], KVM_GET_CLOCK_GUEST, &pvti[idx]);
+ pr_info("vCPU %d: tsc_timestamp=%lu system_time=%lu "
+ "mul=%u shift=%d flags=0x%x\n",
+ idx, (unsigned long)pvti[idx].tsc_timestamp,
+ (unsigned long)pvti[idx].system_time,
+ pvti[idx].tsc_to_system_mul, pvti[idx].tsc_shift,
+ pvti[idx].flags);
+ }
+
+ /* Read guest TSCs: should see (0+OFF) < 2 < (1+OFF) */
+ uint64_t gtsc0 = vcpu_get_msr(vcpus[0], MSR_IA32_TSC);
+ uint64_t gtsc2 = vcpu_get_msr(vcpus[2], MSR_IA32_TSC);
+ uint64_t gtsc1 = vcpu_get_msr(vcpus[1], MSR_IA32_TSC);
+ pr_info("Guest TSCs: vcpu0=%lu vcpu2=%lu vcpu1=%lu\n",
+ (unsigned long)gtsc0, (unsigned long)gtsc2, (unsigned long)gtsc1);
+ pr_info("vcpu0+OFF=%lu vcpu1+OFF=%lu\n",
+ (unsigned long)(gtsc0 + TSC_OFFSET),
+ (unsigned long)(gtsc1 + TSC_OFFSET));
+ TEST_ASSERT(gtsc0 + TSC_OFFSET < gtsc2 && gtsc2 < gtsc1 + TSC_OFFSET,
+ "Expected (vcpu0+OFF) < vcpu2 < (vcpu1+OFF)");
+
+ /* PVCLOCK_TSC_STABLE_BIT should NOT be set (offsets differ) */
+ TEST_ASSERT(!(pvti[2].flags & PVCLOCK_TSC_STABLE_BIT),
+ "PVCLOCK_TSC_STABLE_BIT should NOT be set, flags=0x%x",
+ pvti[2].flags);
+
+ /* Same mul/shift */
+ TEST_ASSERT(pvti[0].tsc_to_system_mul == pvti[2].tsc_to_system_mul &&
+ pvti[0].tsc_shift == pvti[2].tsc_shift,
+ "All vCPUs should have same mul/shift");
+
+ /*
+ * Read host TSC once. At this instant:
+ * vCPU 0 guest TSC = host_tsc + offset0
+ * vCPU 2 guest TSC = host_tsc + offset0 + TSC_OFFSET
+ * Feed each through its pvclock. Expect the same kvmclock.
+ */
+ host_tsc = rdtsc();
+ clk0 = pvclock_calc(&pvti[0], host_tsc + offset0);
+ clk2 = pvclock_calc(&pvti[2], host_tsc + offset0 + TSC_OFFSET);
+
+ pr_info("kvmclock via vCPU 0: %lu ns\n", (unsigned long)clk0);
+ pr_info("kvmclock via vCPU 2: %lu ns\n", (unsigned long)clk2);
+ TEST_ASSERT(clk0 == clk2,
+ "kvmclock from offset vCPUs should match exactly, "
+ "diff=%ld ns", (long)(clk2 - clk0));
+
+ pr_info("PASSED: pvclock consistent across offset vCPUs\n");
+
+ /*
+ * Now add an hour to the VM kvmclock via KVM_SET_CLOCK, run each
+ * vCPU to pick up the update, and check they're still in sync.
+ */
+ {
+#define ONE_HOUR_NS (3600ULL * NSEC_PER_SEC)
+ struct kvm_clock_data setclk = { .clock = clock.clock + ONE_HOUR_NS };
+
+ vm_ioctl(vm, KVM_SET_CLOCK, &setclk);
+ }
+
+ /* Guest code does GUEST_SYNC then exits — run each to see update */
+ for (i = 0; i < 3; i++) {
+ vcpu_run(vcpus[order[i]]);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpus[order[i]], KVM_EXIT_IO);
+ }
+
+ /* Re-read pvclocks */
+ for (i = 0; i < 3; i++)
+ __vcpu_ioctl(vcpus[order[i]], KVM_GET_CLOCK_GUEST, &pvti[order[i]]);
+
+ pr_info("After +1h: vCPU 0 system_time=%lu, vCPU 2 system_time=%lu\n",
+ (unsigned long)pvti[0].system_time,
+ (unsigned long)pvti[2].system_time);
+ TEST_ASSERT(pvti[0].system_time == pvti[2].system_time,
+ "system_time should still match after KVM_SET_CLOCK");
+
+ host_tsc = rdtsc();
+ clk0 = pvclock_calc(&pvti[0], host_tsc + offset0);
+ clk2 = pvclock_calc(&pvti[2], host_tsc + offset0 + TSC_OFFSET);
+
+ pr_info("After +1h: kvmclock via vCPU 0: %lu ns\n", (unsigned long)clk0);
+ pr_info("After +1h: kvmclock via vCPU 2: %lu ns\n", (unsigned long)clk2);
+ TEST_ASSERT(clk0 == clk2,
+ "After +1h: kvmclock should still match, diff=%ld ns",
+ (long)(clk2 - clk0));
+
+ /* Verify the clock actually moved by ~1 hour */
+ TEST_ASSERT(clk0 > ONE_HOUR_NS,
+ "Clock should be > 1 hour after set, got %lu ns",
+ (unsigned long)clk0);
+
+ pr_info("PASSED: pvclock still consistent after KVM_SET_CLOCK +1h\n");
+ kvm_vm_free(vm);
+ return 0;
+}
--
2.54.0
^ permalink raw reply related
* [PATCH v5 02/34] KVM: x86: Improve accuracy of KVM clock when TSC scaling is in force
From: David Woodhouse @ 2026-06-08 14:47 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vitaly Kuznetsov, Juergen Gross, Boris Ostrovsky,
David Woodhouse, Paul Durrant, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
kvm, linux-doc, linux-kernel, xen-devel, linux-kselftest
In-Reply-To: <20260608145455.89187-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
The kvm_guest_time_update() function scales the host TSC frequency to
the guest's using kvm_scale_tsc() and the v->arch.l1_tsc_scaling_ratio
scaling ratio previously calculated for that vCPU. Then calculates the
scaling factors for the KVM clock itself based on that guest TSC
frequency.
However, it uses kHz as the unit when scaling, and then multiplies by
1000 only at the end.
With a host TSC frequency of 3000MHz and a guest set to 2500MHz, the
result of kvm_scale_tsc() will actually come out at 2,499,999kHz. So
the KVM clock advertised to the guest is based on a frequency of
2,499,999,000 Hz.
By using Hz as the unit from the beginning, the KVM clock would be based
on a more accurate frequency of 2,499,999,999 Hz in this example.
Use u64 for the hw_tsc_hz field since an unsigned int would overflow for
TSC frequencies above 4GHz. Use div_u64() for the Xen CPUID leaf to
play nice with 32-bit kernels.
Fixes: 78db6a503796 ("KVM: x86: rewrite handling of scaled TSC for kvmclock")
Reviewed-by: Paul Durrant <paul@xen.org>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/cpuid.c | 2 +-
arch/x86/kvm/x86.c | 17 +++++++++--------
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c470e40a00aa..37264212c7df 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -950,7 +950,7 @@ struct kvm_vcpu_arch {
gpa_t time;
s8 pvclock_tsc_shift;
u32 pvclock_tsc_mul;
- unsigned int hw_tsc_khz;
+ u64 hw_tsc_hz;
struct gfn_to_pfn_cache pv_time;
/* set guest stopped flag in pvclock flags field */
bool pvclock_set_guest_stopped_request;
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index e69156b54cff..621d950ec692 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -2131,7 +2131,7 @@ bool kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx,
*ecx = vcpu->arch.pvclock_tsc_mul;
*edx = vcpu->arch.pvclock_tsc_shift;
} else if (index == 2) {
- *eax = vcpu->arch.hw_tsc_khz;
+ *eax = div_u64(vcpu->arch.hw_tsc_hz, 1000);
}
}
} else {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0a1b63c63d1a..d9ef165df6a1 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3314,7 +3314,8 @@ static void kvm_setup_guest_pvclock(struct pvclock_vcpu_time_info *ref_hv_clock,
int kvm_guest_time_update(struct kvm_vcpu *v)
{
struct pvclock_vcpu_time_info hv_clock = {};
- unsigned long flags, tgt_tsc_khz;
+ unsigned long flags;
+ u64 tgt_tsc_hz;
unsigned seq;
struct kvm_vcpu_arch *vcpu = &v->arch;
struct kvm_arch *ka = &v->kvm->arch;
@@ -3340,8 +3341,8 @@ int kvm_guest_time_update(struct kvm_vcpu *v)
/* Keep irq disabled to prevent changes to the clock */
local_irq_save(flags);
- tgt_tsc_khz = get_cpu_tsc_khz();
- if (unlikely(tgt_tsc_khz == 0)) {
+ tgt_tsc_hz = (u64)get_cpu_tsc_khz() * 1000;
+ if (unlikely(tgt_tsc_hz == 0)) {
local_irq_restore(flags);
kvm_make_request(KVM_REQ_CLOCK_UPDATE, v);
return 1;
@@ -3376,16 +3377,16 @@ int kvm_guest_time_update(struct kvm_vcpu *v)
/* With all the info we got, fill in the values */
if (kvm_caps.has_tsc_control) {
- tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz,
+ tgt_tsc_hz = kvm_scale_tsc(tgt_tsc_hz,
v->arch.l1_tsc_scaling_ratio);
- tgt_tsc_khz = tgt_tsc_khz ? : 1;
+ tgt_tsc_hz = tgt_tsc_hz ? : 1;
}
- if (unlikely(vcpu->hw_tsc_khz != tgt_tsc_khz)) {
- kvm_get_time_scale(NSEC_PER_SEC, tgt_tsc_khz * 1000LL,
+ if (unlikely(vcpu->hw_tsc_hz != tgt_tsc_hz)) {
+ kvm_get_time_scale(NSEC_PER_SEC, tgt_tsc_hz,
&vcpu->pvclock_tsc_shift,
&vcpu->pvclock_tsc_mul);
- vcpu->hw_tsc_khz = tgt_tsc_khz;
+ vcpu->hw_tsc_hz = tgt_tsc_hz;
}
hv_clock.tsc_shift = vcpu->pvclock_tsc_shift;
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox