From nobody Tue Oct 7 06:50:07 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5B1121FBE8A; Sun, 13 Jul 2025 22:20:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.7 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752445240; cv=none; b=K6grWBhShF+bar/+GXD3AIlQ45gyWRmQ+ch99Ks8WIB7PRDY17xpemDo+UHyigYU3kNISIkQ/wKXm/DnNeAzVG5Bh6kpzg8Yw9U1X1T5hBwkcEqXsL3LxGGzcMmiQoPLXrD5qi/FWOL+HWSu/iYb1VdJLymM2F8GwVuH21+fxv4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752445240; c=relaxed/simple; bh=7hpsAL4qmfbba/iVBinYIHn//Gv9UHE9xVzc4KyCfcw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DPPob3wjCmw0x7iVZqAapelrhrZIEpNuBdiV7JRFgD4U+udsI+z6xwJHFME2MbQmDCqGjWZo8iCXGCOFJxrQBZyPMKsEPDyo7PWsjuSYX7GMh99Ri0OFmUwekM0wDSyy+a6wBXCgDkuK8wQmf+9RW+xMnC1szYLUmipF1hJQ/GU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=m3zeSa7c; arc=none smtp.client-ip=192.198.163.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="m3zeSa7c" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752445239; x=1783981239; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=7hpsAL4qmfbba/iVBinYIHn//Gv9UHE9xVzc4KyCfcw=; b=m3zeSa7cmrWSv8dtyRCLemAyKkfOXWqg2PNSk/5wIms/kVlTVwqVIidQ TiJjroh2TnVDMmPPFKzyCH35/972Wvzzb5GrnhCoDXXgFMPVIT4SQPYxe k82zs5sVn4hrkdNJLa2v2Pg0YSgbXAyw032HL3NNSZOREjv5MjMquKNjj kkIBoU0U0rS5j64f2SIjcnLn/5FJI0PKd5aiIuErajuuTtGuhw9FTBNXG whAOExoOWCDhojYaoHkmHK7j911bu4Dzaj59ueqeBcrjC8ECSltFR+PFO pbEPM26JLmn8vBqCQKwdEFeCZTwETh3d9lq6JmsJ4757fVZeWYQznOTsE A==; X-CSE-ConnectionGUID: U+E5/0XiRxy6EmFWm0Z8qw== X-CSE-MsgGUID: UtyhDKNYQneWF1VuisISTg== X-IronPort-AV: E=McAfee;i="6800,10657,11491"; a="80077245" X-IronPort-AV: E=Sophos;i="6.16,309,1744095600"; d="scan'208";a="80077245" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2025 15:20:38 -0700 X-CSE-ConnectionGUID: d3kZlVwcROm6VnHEIiYTcA== X-CSE-MsgGUID: +Yn9X7bjSHGdNicWV/WJ0Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,309,1744095600"; d="scan'208";a="156891924" Received: from gpacheco-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.124.223.7]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2025 15:20:35 -0700 From: Kai Huang To: seanjc@google.com, pbonzini@redhat.com Cc: kvm@vger.kernel.org, thomas.lendacky@amd.com, nikunj@amd.com, bp@alien8.de, isaku.yamahata@intel.com, xiaoyao.li@intel.com, rick.p.edgecombe@intel.com, chao.gao@intel.com, linux-kernel@vger.kernel.org Subject: [PATCH v2 1/2] KVM: x86: Reject KVM_SET_TSC_KHZ VM ioctl when vCPUs have been created Date: Mon, 14 Jul 2025 10:20:19 +1200 Message-ID: <135a35223ce8d01cea06b6cef30bfe494ec85827.1752444335.git.kai.huang@intel.com> X-Mailer: git-send-email 2.50.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Reject the KVM_SET_TSC_KHZ VM ioctl when vCPUs have been created and update the documentation to reflect it. The VM scope KVM_SET_TSC_KHZ ioctl is used to set up the default TSC frequency that all subsequently created vCPUs can use. It is only intended to be called before any vCPU is created. Allowing it to be called after that only results in confusion but nothing good. Note this is an ABI change. But currently in Qemu (the de facto userspace VMM) only TDX uses this VM ioctl, and it is only called once before creating any vCPU, therefore the risk of breaking userspace is pretty low. Suggested-by: Sean Christopherson Signed-off-by: Kai Huang Reviewed-by: Xiaoyao Li Reviewed-by: Chao Gao Reviewed-by: Nikunj A Dadhania --- Documentation/virt/kvm/api.rst | 2 +- arch/x86/kvm/x86.c | 9 ++++++--- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 43ed57e048a8..e343430ccb01 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -2006,7 +2006,7 @@ frequency is KHz. =20 If the KVM_CAP_VM_TSC_CONTROL capability is advertised, this can also be used as a vm ioctl to set the initial tsc frequency of subsequently -created vCPUs. +created vCPUs. The vm ioctl must be called before any vCPU is created. =20 4.56 KVM_GET_TSC_KHZ -------------------- diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 2806f7104295..4051c0cacb92 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7199,9 +7199,12 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned in= t ioctl, unsigned long arg) if (user_tsc_khz =3D=3D 0) user_tsc_khz =3D tsc_khz; =20 - WRITE_ONCE(kvm->arch.default_tsc_khz, user_tsc_khz); - r =3D 0; - + mutex_lock(&kvm->lock); + if (!kvm->created_vcpus) { + WRITE_ONCE(kvm->arch.default_tsc_khz, user_tsc_khz); + r =3D 0; + } + mutex_unlock(&kvm->lock); goto out; } case KVM_GET_TSC_KHZ: { --=20 2.50.0 From nobody Tue Oct 7 06:50:07 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A5D1E2046A9; Sun, 13 Jul 2025 22:20:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.7 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752445243; cv=none; b=iY33G1KNQX7iCyLI7rU2AEWw7RnakgrzfJkRWaUh8ugUtoefrNWl0AJKTtTNUOZmRdnB8sJ314dZBnAfrgpUVsFSKfDSNI5xxNTXty7h9rUmRaMVj6rBKd35ZCeLqCd5sRcn1SU6QfTesRR/2jdDKZa2NRCU/PEFE9ZgKwBz/2g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752445243; c=relaxed/simple; bh=Evzy0z8dVOISDH5lXgms8Aq3Kfyn1mwy+RJB/+zm9Ow=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UBPP9j/oxr9JqBAspcquIw8/E2DPP0VHCZK9Y2KWJbNNJ5UjN8JtZzmcOQNUSqp9XSk+m0Hue8Cyf2DDw4leE/l8uLK4Zd1dhObbdSXRe5XkKPgQbMobffvM/nnWwwSWutJitDuite/I84xRjJmiV63MTVooACn6hObMvy3Tnh0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=M5NecNqW; arc=none smtp.client-ip=192.198.163.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="M5NecNqW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752445242; x=1783981242; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Evzy0z8dVOISDH5lXgms8Aq3Kfyn1mwy+RJB/+zm9Ow=; b=M5NecNqWoFRIsHOnB79Zmyd6ZC/qOB2U9fPCY9dTr5TYDeNPSfPl2o2t bwCu7dDhybZlwdPa/r6l1MYWqJePXf7tc781h3m8wvUn8gNibj7jYeaQo Nc2z4LdWy8FP62b0iaSUD4j5Yj/A3QNpFsr6kwZfuK7yVtLEIBI6nSY1p c6cSuavl4PBOEQhP4V7SRNSX4kqs7XMm5s7bkQeNt4c0vaR7NEesCXsZ5 kKWfSv3joqHTNDAcqvY8c1yOUj0J86nMnMPzaORMYiz3UrhIaNxZktV/V rX33SLuz1q8sXRVAetd7qoO/LXhkmnKZHh67r4W+UWpd5L3MvrVyW40V4 Q==; X-CSE-ConnectionGUID: p9fIXb7RShu2fTc8bOKqqA== X-CSE-MsgGUID: 5bF3lHYOSxSeSNW3xMrKhg== X-IronPort-AV: E=McAfee;i="6800,10657,11491"; a="80077254" X-IronPort-AV: E=Sophos;i="6.16,309,1744095600"; d="scan'208";a="80077254" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2025 15:20:42 -0700 X-CSE-ConnectionGUID: 37v/o9/oR3iteh3zY9Io2g== X-CSE-MsgGUID: ZPozDmYRSW2VIlKne1TC+Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,309,1744095600"; d="scan'208";a="156891933" Received: from gpacheco-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.124.223.7]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2025 15:20:38 -0700 From: Kai Huang To: seanjc@google.com, pbonzini@redhat.com Cc: kvm@vger.kernel.org, thomas.lendacky@amd.com, nikunj@amd.com, bp@alien8.de, isaku.yamahata@intel.com, xiaoyao.li@intel.com, rick.p.edgecombe@intel.com, chao.gao@intel.com, linux-kernel@vger.kernel.org Subject: [PATCH v2 2/2] KVM: x86: Reject KVM_SET_TSC_KHZ vCPU ioctl for TSC protected guest Date: Mon, 14 Jul 2025 10:20:20 +1200 Message-ID: <71bbdf87fdd423e3ba3a45b57642c119ee2dd98c.1752444335.git.kai.huang@intel.com> X-Mailer: git-send-email 2.50.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Reject KVM_SET_TSC_KHZ vCPU ioctl if guest's TSC is protected and not changeable by KVM, and update the documentation to reflect it. For such TSC protected guests, e.g. TDX guests, typically the TSC is configured once at VM level before any vCPU are created and remains unchanged during VM's lifetime. KVM provides the KVM_SET_TSC_KHZ VM scope ioctl to allow the userspace VMM to configure the TSC of such VM. After that the userspace VMM is not supposed to call the KVM_SET_TSC_KHZ vCPU scope ioctl anymore when creating the vCPU. The de facto userspace VMM Qemu does this for TDX guests. The upcoming SEV-SNP guests with Secure TSC should follow. Note this could be a break of ABI. But for now only TDX guests are TSC protected and only Qemu supports TDX, thus in practice this should not break any existing userspace. Suggested-by: Sean Christopherson Signed-off-by: Kai Huang Reviewed-by: Xiaoyao Li Reviewed-by: Nikunj A Dadhania --- Documentation/virt/kvm/api.rst | 7 +++++++ arch/x86/kvm/x86.c | 4 ++++ 2 files changed, 11 insertions(+) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index e343430ccb01..563878465a6a 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -2008,6 +2008,13 @@ If the KVM_CAP_VM_TSC_CONTROL capability is advertis= ed, this can also be used as a vm ioctl to set the initial tsc frequency of subsequently created vCPUs. The vm ioctl must be called before any vCPU is created. =20 +For TSC protected Confidential Computing (CoCo) VMs where TSC frequency +is configured once at VM scope and remains unchanged during VM's +lifetime, the vm ioctl should be used to configure the TSC frequency +and the vcpu ioctl is not supported. + +Example of such CoCo VMs: TDX guests. + 4.56 KVM_GET_TSC_KHZ -------------------- =20 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 4051c0cacb92..26737bc4decb 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -6186,6 +6186,10 @@ long kvm_arch_vcpu_ioctl(struct file *filp, u32 user_tsc_khz; =20 r =3D -EINVAL; + + if (vcpu->arch.guest_tsc_protected) + goto out; + user_tsc_khz =3D (u32)arg; =20 if (kvm_caps.has_tsc_control && --=20 2.50.0