From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5EF5A30499C for ; Thu, 4 Sep 2025 13:26:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756992364; cv=none; b=tSqYMTxlOCYW0LnYx300ErJKYCHkxBeDnxaYFXZeOGYN3BXSxUopadPwWGbUdvfhjo+nQKoDZgkTTg0RmhGh/kAL+U5MbIpOw9tSZ09CBWZV/gEYcO5y2kMrtDGTRHd+pjU42s73F84caT7M5+/2YjQgGPPbFyGNvjm24VmngD8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756992364; c=relaxed/simple; bh=K1N3OVD/4jIwE/loNZvU5ggVqQw/2Ae0TTFxNtyKH4g=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=W+a/URyCYQuNAywumC8g7lhRLFIiIvWBN6RqPN2tEiQxe3UYiwSF4arvcZkyLLP+5UcE2ULg7V31sX7oByzNOEsXOCNJdSA/QMVh84GEBfkTrvoH8UeSDDdjsln2lcmR75GF+pmdSZ/oHywiZ8zEValJH2KDqCZ1OPfthf1lLjA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=fj8myLcv; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="fj8myLcv" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-324e41e946eso1725992a91.0 for ; Thu, 04 Sep 2025 06:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1756992363; x=1757597163; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=qCN6Pj+XCmAisjcedbovVIrUMZAHherYJ0sw+9bB0a8=; b=fj8myLcvBDDeB3gwZrdY/pOxL9soNpTplK17Ljt5p550uMj/lEmx9RUL3ysSE9Aq8J NFZ6JCJQ7g+9TE/mkreA8P4JDZeNog3KTiR4Bf/s/WLVMVr1Mvplut5bI09LqkUugoDl 8oFAeW51BAzmkGnrXr/yFhsfi3A5EeDrQWpGGw7MFYGBGh4z3w+BzcvWpGD33/XYGO/H zwxmUVV3YQy7O68A3WHWY1ynoMgBIZm1EEpRbz0noimOKX5HU0H6KG5biukUyKuFKOkj hTLavhFUvxcebwpe7be14qpPG4PDLbMApwFSANdwsOaZoDnrKZq99JsbpWbuNCBtRw11 BwlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756992363; x=1757597163; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=qCN6Pj+XCmAisjcedbovVIrUMZAHherYJ0sw+9bB0a8=; b=WyCX7i14hj5w01V4H2GFeMHr4qAMCW4f0504ShaZamKaQivETsUpOTceLN6SAnAQ1o 61G233PLb8Ak+Pqr8UVOlMTclnYGwhcRRjitqgnBPVAebEYfcG/23tcKP8pxf2i8EPz2 1kGAXnDfrq5TxCwJBOeFmGhpbQ++4ul4SsFJonFtu94Msws98CQse+sAdNZk5TmfC5st 9SnD3pz4Q3X5RQKxPYYUU/i0Ebvo5tMw3qPxh2qlg6iZm7m8GBXExxKzj/sqvl4ZRLJz oN30Z4QKt8NCJ54T6WfJT5ttsL+CHa6NUYthD8R3oMAMijMpsRXR2jSSy+D/Um27QvGF nfZA== X-Forwarded-Encrypted: i=1; AJvYcCX9JeJQMGj69APsztvYsVsLeym31IN4SWz2yrvD8ZpTrcn31Z6iPYv5etNagoHnvz1pYVU=@vger.kernel.org X-Gm-Message-State: AOJu0Ywy73lSv0lVUSLA5JrFBH/fW5E5i/UerCaVslrEvprYhY4GQQbm mg2el8FAa2u6C3or/clchyN4uHt+L0elN7jxIM+3et40vzBBWNRjGOWEXgr5U5xxUiV+RScSldx AgQSSSw== X-Google-Smtp-Source: AGHT+IFz/vMO7oju85LfKzZ0R59IVu4BeGepAEN+RnQCU8o5CkJAM/GgwVJDXN02zuFjtWPwhmtEqhNRTYI= X-Received: from pjbqn11.prod.google.com ([2002:a17:90b:3d4b:b0:321:c2a7:cbce]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:1845:b0:32b:9ede:bfd2 with SMTP id 98e67ed59e1d1-32b9edec1b8mr1864950a91.22.1756992362639; Thu, 04 Sep 2025 06:26:02 -0700 (PDT) Date: Thu, 4 Sep 2025 06:25:49 -0700 In-Reply-To: <4a3be390fe559de0bd5c61d24853d88f96a6ab6a.camel@infradead.org> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <54BCC060-1C9B-4BE4-8057-0161E816A9A3@amazon.co.uk> <3268e953e14004d1786bf07c76ae52d98d0f8259.camel@infradead.org> <4a3be390fe559de0bd5c61d24853d88f96a6ab6a.camel@infradead.org> Message-ID: Subject: Re: [PATCH v2 0/3] Support "generic" CPUID timing leaf as KVM guest and host From: Sean Christopherson To: David Woodhouse Cc: Paul Durrant , Fred Griffoul , Colin Percival , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "x86@kernel.org" , "H. Peter Anvin" , Vitaly Kuznetsov , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Graf (AWS), Alexander" , Ajay Kaher , Alexey Makhalov Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 04, 2025, David Woodhouse wrote: > On Thu, 2025-09-04 at 04:59 -0700, Sean Christopherson wrote: > >=20 > > I thought the original problem being solved was that the _guest_ doesn'= t know the > > effective TSC frequency?=C2=A0 Userspace can already get the effectivel= y TSC frequency > > via KVM_GET_TSC_KHZ, why do we need another uAPI to provide that?=C2=A0= (Honest question, > > I feel like I'm missing something) >=20 > I believe that KVM_GET_TSC_KHZ returns what userspace *asked* for the > TSC frequency to be (vcpu->arch.virtual_tsc_khz), not what it actually > ended up being based on the measured host frequency and the available > scaling granularity (vcpu->hw_tsc_khz). Ah, I see where you're coming from. Purely out of curiosity, have you done= the math to see if slop would be a problem in practice? No worries if you have= n't, just genuinely (and lazily) curious. Anyways, I'm a-ok reporting that information in KVM_GET_SUPPORTED_CPUID (ag= ain, only with constant TSC and scaling). Reporting the effective frequency wou= ld be useful for the host too, e.g. for sanity checks. What I specifically want = to avoid is modifying guest CPUID at runtime. Hmm, the only wrinkle is that, if there is slop, KVM could report different information when run on different platforms, e.g. after live migration. Bu= t so long as that possibility is documented, I don't think it's truly problemati= c. And it's another argument for not modifying guest CPUID directly; I'd rathe= r let userspace figure out whether or not they care about the divergence than sil= ently change things from the guest's perspective. Alternatively (or in addition to), part of me wants to stealtily update KVM_GET_TSC_KHZ to report back the effective frequency, but I can see that = being problematic, e.g. if a naive VMM reads KVM_GET_TSC_KHZ when saving vCPU sta= te for live migration and after enough migrations, the slop ends up drastically sk= ewing the guest's frequency.