From patchwork Sat Oct 12 07:55:55 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Isaku Yamahata X-Patchwork-Id: 13833906 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 7363113B7BC; Sat, 12 Oct 2024 07:56:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728719774; cv=none; b=lvdaGfx1rt5GJ/nhdm8EStzDaeiUuQ+2sWf4uuyrYLhDIATYmV3pmTQHxdQFt+jzjpNoe/Q+fSYGgVJ+e9j7HJbaZnbdfRZ/me6IWWXTuqoaIYs1VfJ69H7LV1an1XVKAKak9pOrnTEAk4ga3ZvM7uBSSxv16hGSzNfzupdJt3A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728719774; c=relaxed/simple; bh=Z4r6YlfUbeU/3Vc1bRAgwqZUf48Vf50QTA+ykifcW2k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GQREay47M4uGXdSMP4b5DQ7duIaSzAD4fBB+eiPMrQ+sE1JdwhAITbV1yw5MwPpR66pBvO7QmOuWGZJ89BuWMapQsR8PC785pL4nAI2hfAdGnmOoeNjqufnQX5SOXojS5fqVz+L+rk7UgjLgEw6P2cfIu56d/3asP7Q2igIIjSk= 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=k/Fh5Bzm; arc=none smtp.client-ip=192.198.163.10 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="k/Fh5Bzm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728719773; x=1760255773; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Z4r6YlfUbeU/3Vc1bRAgwqZUf48Vf50QTA+ykifcW2k=; b=k/Fh5Bzmu02cKY7oQKGqs2nGj6wz58MAR7J4y9kEcrYAPq2uvxBEZulV j/ftMUt1Q+GqBh6+QM8+fYEZaSFp6U3zac4/TuPyNRLIe8Yv7xNf71XSb wpoqZ06Zl0mj6jEyi8XVjR6Ny4GWBVfrXol0V3SknKt7BDJEIOYSLPtV/ ZNiQEBhtVzSSJ+NhZzMQPNEtYHXwpB6Jfr0f8aLLSZe3vPuHC6JUhvVTM lebF2UowC6BoU21U5u9o9hjmgKFPNv5evckOEiPZeBAnlZHSVUAhwVtd1 3DQV2dvtXnOI543pSSMtCt/AYgGCQwKsxUeCfz4EgagL2KQeshe54whIq g==; X-CSE-ConnectionGUID: Gzs99NopRJmDtga/DmFkNQ== X-CSE-MsgGUID: DWRCZJZlSD+Y4JYNTBYSQA== X-IronPort-AV: E=McAfee;i="6700,10204,11222"; a="39510289" X-IronPort-AV: E=Sophos;i="6.11,198,1725346800"; d="scan'208";a="39510289" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2024 00:56:09 -0700 X-CSE-ConnectionGUID: luuAxlURTr+oWa4OYWzoBg== X-CSE-MsgGUID: So5Y1WThQTWb4yQ7kcacow== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,198,1725346800"; d="scan'208";a="82116739" Received: from ls.amr.corp.intel.com (HELO localhost) ([172.25.112.54]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2024 00:56:09 -0700 From: Isaku Yamahata To: kvm@vger.kernel.org, pbonzini@redhat.com Cc: Sean Christopherson , chao.gao@intel.com, isaku.yamahata@intel.com, rick.p.edgecombe@intel.com, yan.y.zhao@intel.com, linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com, Nikunj A Dadhania , Marcelo Tosatti Subject: [PATCH 1/2] KVM: x86: Push down setting vcpu.arch.user_set_tsc Date: Sat, 12 Oct 2024 00:55:55 -0700 Message-ID: <62b1a7a35d6961844786b6e47e8ecb774af7a228.1728719037.git.isaku.yamahata@intel.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: References: Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Push down setting vcpu.arch.user_set_tsc to true from kvm_synchronize_tsc() to __kvm_synchronize_tsc() so that the two callers don't have to modify user_set_tsc directly as preparation. Later, prohibit changing TSC synchronization for TDX guests to modify __kvm_synchornize_tsc() change. We don't want to touch caller sites not to change user_set_tsc. Signed-off-by: Isaku Yamahata --- arch/x86/kvm/x86.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index cb24e394d768..65d871bb5b35 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2644,12 +2644,15 @@ static inline bool kvm_check_tsc_unstable(void) * participates in. */ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc, - u64 ns, bool matched) + u64 ns, bool matched, bool user_set_tsc) { struct kvm *kvm = vcpu->kvm; lockdep_assert_held(&kvm->arch.tsc_write_lock); + if (user_set_tsc) + vcpu->kvm->arch.user_set_tsc = true; + /* * We also track th most recent recorded KHZ, write and time to * allow the matching interval to be extended at each write. @@ -2735,8 +2738,6 @@ static void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value) } } - if (user_value) - kvm->arch.user_set_tsc = true; /* * For a reliable TSC, we can match TSC offsets, and for an unstable @@ -2756,7 +2757,7 @@ static void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value) matched = true; } - __kvm_synchronize_tsc(vcpu, offset, data, ns, matched); + __kvm_synchronize_tsc(vcpu, offset, data, ns, matched, !!user_value); raw_spin_unlock_irqrestore(&kvm->arch.tsc_write_lock, flags); } @@ -5760,8 +5761,7 @@ static int kvm_arch_tsc_set_attr(struct kvm_vcpu *vcpu, tsc = kvm_scale_tsc(rdtsc(), vcpu->arch.l1_tsc_scaling_ratio) + offset; ns = get_kvmclock_base_ns(); - kvm->arch.user_set_tsc = true; - __kvm_synchronize_tsc(vcpu, offset, tsc, ns, matched); + __kvm_synchronize_tsc(vcpu, offset, tsc, ns, matched, true); raw_spin_unlock_irqrestore(&kvm->arch.tsc_write_lock, flags); r = 0; From patchwork Sat Oct 12 07:55:56 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Isaku Yamahata X-Patchwork-Id: 13833907 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 F0B0B142900; Sat, 12 Oct 2024 07:56:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728719775; cv=none; b=NeJcv76jsdRY3nPrsZOPAZZRiUGM56aohfzwSczZ5ikvBTvl7QqZP2NX0QI7QMlA2BZxQq98h8wM2f/3pmkvmGWQoQD1fXZDw/HNZyeXwXbAnK5LPEeJNfgU74dUKbnBMIkCGpxJQH9iBPtLtGdsSD7SPK/xqwgYC7qarlsURDk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728719775; c=relaxed/simple; bh=rRvsmBeBTUCzqKK3se1PbVcX4TxQnKcMtvBQ6wWmjms=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JbHBI4H+4mO06l0Nq4cs6ALhKB96U3oh5Heo3qUegDg63JCyqWJpL6pX9FSdNX1En9aaEBwN4TyRMcJcckirHSWaSKuNnYPV40I9vgQZKdeAAxKzfvBbDeNjojvYj17Mt94XfC90BCkI4+hvI8HnhimUkmqCIh5gyNLlroF5aYA= 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=ScQ4aNqo; arc=none smtp.client-ip=192.198.163.10 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="ScQ4aNqo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728719773; x=1760255773; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=rRvsmBeBTUCzqKK3se1PbVcX4TxQnKcMtvBQ6wWmjms=; b=ScQ4aNqoBBdBYk3MQvVbUpJ8ZcsMdChPnrQMAFydvYFbiEkn0LJ6Vlpe mlyMJ5owtsrW0KbPoTxl3vKnAKxpBcbz99fKbgB+LSE8MmfEabeXp3AgO tDXsGxbjD4zC3/suXlOnk3XXLaX7KaP/sYKqNp3wwi+m5sd6Zzvmrz5V4 KJs/xzVpWZ79kSebzeBpXeE3UDm2EJ1TLAaE6FP7hGfeUjyz+qX3doQWf tOAxumg0sryidLzQywBlXJXQME4yrYq7PtN1TVNE3DEE9/X0EddOrbNUc aoOpoM3HdJC2Pgbww8cf8vhHxOiRCFyx9OgYjw0V3FiwR82CW+YBl8G/O g==; X-CSE-ConnectionGUID: Diol7w/lSC2s92XypXbR8Q== X-CSE-MsgGUID: A8AKnSTjSrW1hntbP3h1NA== X-IronPort-AV: E=McAfee;i="6700,10204,11222"; a="39510294" X-IronPort-AV: E=Sophos;i="6.11,198,1725346800"; d="scan'208";a="39510294" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2024 00:56:10 -0700 X-CSE-ConnectionGUID: gbdsctEqRnuENEGHq2f8sQ== X-CSE-MsgGUID: BwaPHN5ET2qkteYlClU8uw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,198,1725346800"; d="scan'208";a="82116742" Received: from ls.amr.corp.intel.com (HELO localhost) ([172.25.112.54]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2024 00:56:09 -0700 From: Isaku Yamahata To: kvm@vger.kernel.org, pbonzini@redhat.com Cc: Sean Christopherson , chao.gao@intel.com, isaku.yamahata@intel.com, rick.p.edgecombe@intel.com, yan.y.zhao@intel.com, linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com, Nikunj A Dadhania , Marcelo Tosatti Subject: [PATCH 2/2] KVM: x86: Don't allow tsc_offset, tsc_scaling_ratio to change Date: Sat, 12 Oct 2024 00:55:56 -0700 Message-ID: <3a7444aec08042fe205666864b6858910e86aa98.1728719037.git.isaku.yamahata@intel.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: References: Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Add guest_tsc_protected member to struct kvm_arch_vcpu and prohibit changing TSC offset/multiplier when guest_tsc_protected is true. Background X86 confidential computing technology defines protected guest TSC so that the VMM can't change the TSC offset/multiplier once vCPU is initialized. The SEV-SNP defines Secure TSC as optional. TDX mandates it. The TDX module determines the TSC offset/multiplier. The VMM has to retrieve them. On the other hand, the x86 KVM common logic tries to guess or adjust TSC offset/multiplier for better guest TSC and TSC interrupt latency at KVM vCPU creation (kvm_arch_vcpu_postcreate()), vCPU migration over pCPU (kvm_arch_vcpu_load()), vCPU TSC device attributes (kvm_arch_tsc_set_attr()) and guest/host writing to TSC or TSC adjust MSR (kvm_set_msr_common()). Problem The current x86 KVM implementation conflicts with protected TSC because the VMM can't change the TSC offset/multiplier. Disable or ignore the KVM logic to change/adjust the TSC offset/multiplier somehow. Because KVM emulates the TSC timer or the TSC deadline timer with the TSC offset/multiplier, the TSC timer interrupts is injected to the guest at the wrong time if the KVM TSC offset is different from what the TDX module determined. Originally this issue was found by cyclic test of rt-test [1] as the latency in TDX case is worse than VMX value + TDX SEAMCALL overhead. It turned out that the KVM TSC offset is different from what the TDX module determines. Solution The solution is to keep the KVM TSC offset/multiplier the same as the value of the TDX module somehow. Possible solutions are as follows. - Skip the logic Ignore (or don't call related functions) the request to change the TSC offset/multiplier. Pros - Logically clean. This is similar to the guest_protected case. Cons - Needs to identify the call sites. - Revert the change at the hooks after TSC adjustment x86 KVM defines the vendor hooks when TSC offset/multiplier are changed. The callback can revert the change. Pros - We don't need to care about the logic to change the TSC offset/multiplier. Cons: - Hacky to revert the KVM x86 common code logic. Choose the first one. With this patch series, SEV-SNP secure TSC can be supported. [1] https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git Reported-by: Marcelo Tosatti Signed-off-by: Isaku Yamahata --- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/x86.c | 9 ++++++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 61b7e9fe5e57..112b8a4f1860 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1036,6 +1036,7 @@ struct kvm_vcpu_arch { /* Protected Guests */ bool guest_state_protected; + bool guest_tsc_protected; /* * Set when PDPTS were loaded directly by the userspace without diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 65d871bb5b35..a6cf4422df28 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2587,6 +2587,9 @@ EXPORT_SYMBOL_GPL(kvm_calc_nested_tsc_multiplier); static void kvm_vcpu_write_tsc_offset(struct kvm_vcpu *vcpu, u64 l1_offset) { + if (vcpu->arch.guest_tsc_protected) + return; + trace_kvm_write_tsc_offset(vcpu->vcpu_id, vcpu->arch.l1_tsc_offset, l1_offset); @@ -2650,6 +2653,9 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc, lockdep_assert_held(&kvm->arch.tsc_write_lock); + if (vcpu->arch.guest_tsc_protected) + return; + if (user_set_tsc) vcpu->kvm->arch.user_set_tsc = true; @@ -5028,7 +5034,8 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu) u64 offset = kvm_compute_l1_tsc_offset(vcpu, vcpu->arch.last_guest_tsc); kvm_vcpu_write_tsc_offset(vcpu, offset); - vcpu->arch.tsc_catchup = 1; + if (!vcpu->arch.guest_tsc_protected) + vcpu->arch.tsc_catchup = 1; } if (kvm_lapic_hv_timer_in_use(vcpu))