Steal time is the time a virtual CPU was ready to run but waited for the host to schedule it. For example, in a 100 ms interval a vCPU might run for 70 ms and wait 30 ms for a physical CPU. Reporting those 30 ms lets Linux: - account CPU usage accurately, without charging applications for time their vCPU wasn't running; - base scheduling decisions on the CPU time tasks actually received; - show host contention in the "st" column of top and vmstat and in /proc/stat.
VMware writes a running total into a small per-CPU buffer in guest memory, and Linux reads it. In a confidential guest (AMD SEV-SNP, Intel TDX) memory is private by default and the host cannot write it, so the guest has to share the buffer first. Linux currently registers the buffer without sharing it, and ESXi then powers off the VM. This only affects VMs with the steal clock enabled, which ESXi enables by default only for Photon guests. Following the v2 discussion, this version uses one packed allocation for all possible CPUs' counters and shares it before registering any address. Setup moves to an early initcall so it can use the normal memory-conversion API. This avoids converting a page in every CPU's per-CPU area and concentrates sharing in one allocation. Changes since v2: - Replace the six infrastructure patches with one VMware-only fix. - Leave the per-CPU allocator, linker, KVM and early conversion code alone. - Move ordinary-guest setup to the same initcall. - Rebase onto v7.3. Tested on ordinary VMware x86-64 SMP/UP guests, ESXi SEV-SNP and TDX guests (SMP, UP, 66 vCPUs and percpu_alloc=page), and QEMU/KVM x86-64 guests. v2: https://lore.kernel.org/r/[email protected] Zack Rusin (1): x86/vmware: Allocate shared storage for steal-time counters arch/x86/kernel/cpu/vmware.c | 130 +++++++++++++++++++++++------------ 1 file changed, 86 insertions(+), 44 deletions(-) base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
