From nobody Thu Oct 2 02:15:18 2025 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (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 D03C6263F44 for ; Tue, 23 Sep 2025 15:37:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758641868; cv=none; b=k2s4QeuOo9yeNyBxoLNgrTMxisTHrx+otD4PxEh/9yInbjwJcVYk2KRakx1RnBWhj32TZatU8nNf3d5FlFBFQ+iQ1O58DD19A5Rd/wPhx7NuZzxdumkNJC/jLk9lo6iJAnVcD6AXmy1OcCGLAaGX422Nn/PAiBdq8CvSNlvZE/Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758641868; c=relaxed/simple; bh=4swEKEjr9ZfU+UhcssFhlBXgoat9+0rZuV4f1sVbGQk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ZbXJ16LiK+vegIf2u0DcRRV/ZmW8onjwk48imDh59GAHB7ukpgVrmGeXCziNvvrbbxg2KTcgOAHJAqhwmsJkWQ01ESCqSOlDuzp4scrVmj5R1UI3Y03uLgLgLiFOrktNSfCFZWLQT5OQJ5TVkxAh45fUy/X4QYV00OiCpWrpcqU= 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=AHJUA1vr; arc=none smtp.client-ip=209.85.215.202 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="AHJUA1vr" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-b54df707c1cso3486795a12.2 for ; Tue, 23 Sep 2025 08:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1758641866; x=1759246666; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=RPQBXX/kV1DT6qccrRylEa2l6eEjE9QWLJ5e48WHMIs=; b=AHJUA1vrowf9iGV/k69rs8bWenM5WVB/6ero/JywlrgUES2exNT6+QZwldL3BvlTRg 9/nbI9k79EkZbdd83irH3kV+unZHYmo+rbOrPf2iyqgjPjvgNVK979JRGs9Bf85Q6oe5 pqp/DrZx1cBa/vWs5SUOCToh69SVbClFB9i5BADXhYipMbsO0hgJ/dt/eTognteqN5CM ikM6wpnkEFuz/cdOSNg1oBZ8aTGeYej80vo9OFvwRfEOkKmKSOScTXFW8qg0DI27+QtW 7S1Kdc9Hi14bqDCml/+vNWqb8r8DGhI+eiAiebd5D4IKtmJyf/3gLdgsG764yJagLs+M ogGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758641866; x=1759246666; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RPQBXX/kV1DT6qccrRylEa2l6eEjE9QWLJ5e48WHMIs=; b=Gb1kpDmf6691z8Od4Nml2QnJaRMHmeCnGhZ0JOcgcorjlxVI2Xb5EqTRyrkOUBk8I7 btyx98SDYf1GpHJMy3dSCu1ScbbEGJi0fruKMXV6oBOxq9QfQb6wYt9VIXLSfz+5OI2+ UmhGGqy3NhkxMtQYqIkt50lY29R3QBkQk7mrJvw5wv1uH5nPd7SbTky1YF0eNYUtQVRL NUYxCnjx5ppAQE4pFrzRBuNSE0Un3GmD2HRTVk4E5YNmYyZ2GOBlp134eeL4Jrx0OWoI jFoHfzHxhPiuOwWkW8HVPoAcwC6UpGjs6IkjMPZan28MVgIzyFkROhEU9CoNDkEjoTMA szDw== X-Forwarded-Encrypted: i=1; AJvYcCWfk8dVmOynwolUGkswz8SUbh0GI8l5PtiZesfJHC0pGMb/PgBXYe84YygFqzYRBTBHEjmdb6Dv0J2xPoQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyDk4VBscLtcT0D7rVdioynsdP7+xEK/2O6bWY2N2dIyiGNVwJb 7iKBj7OyVud1ge9e48VM+5du4x2b0vi8HvbaYrnLweD0HzOT6rgDN4oWgDc6tqIVa7GZVVrkYCs iCJvoog== X-Google-Smtp-Source: AGHT+IErLLqmD/PORlhyxU7jOUm4C+LioX2IifX5+KrKCfJkXml7M7iR2w0tUMSLgBWIeNxBWpYKDngkc0Y= X-Received: from pjtt1.prod.google.com ([2002:a17:90a:1c81:b0:332:8389:c569]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:2442:b0:24c:ed95:2725 with SMTP id d9443c01a7336-27cc28bc310mr34259705ad.4.1758641866139; Tue, 23 Sep 2025 08:37:46 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 23 Sep 2025 08:37:37 -0700 In-Reply-To: <20250923153738.1875174-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250923153738.1875174-1-seanjc@google.com> X-Mailer: git-send-email 2.51.0.534.gc79095c0ca-goog Message-ID: <20250923153738.1875174-2-seanjc@google.com> Subject: [PATCH v3 1/2] KVM: x86: Add helper to retrieve current value of user return MSR From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Hou Wenlong , Xiaoyao Li , Lai Jiangshan Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hou Wenlong In the user return MSR support, the cached value is always the hardware value of the specific MSR. Therefore, add a helper to retrieve the cached value, which can replace the need for RDMSR, for example, to allow SEV-ES guests to restore the correct host hardware value without using RDMSR. Cc: stable@vger.kernel.org Signed-off-by: Hou Wenlong [sean: drop "cache" from the name, make it a one-liner, tag for stable] Reviewed-by: Xiaoyao Li Signed-off-by: Sean Christopherson --- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/x86.c | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index 17772513b9cc..14236006266b 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -2376,6 +2376,7 @@ int kvm_add_user_return_msr(u32 msr); int kvm_find_user_return_msr(u32 msr); int kvm_set_user_return_msr(unsigned index, u64 val, u64 mask); void kvm_user_return_msr_update_cache(unsigned int index, u64 val); +u64 kvm_get_user_return_msr(unsigned int slot); =20 static inline bool kvm_is_supported_user_return_msr(u32 msr) { diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index e07936efacd4..801bf6172a21 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -675,6 +675,12 @@ void kvm_user_return_msr_update_cache(unsigned int slo= t, u64 value) } EXPORT_SYMBOL_GPL(kvm_user_return_msr_update_cache); =20 +u64 kvm_get_user_return_msr(unsigned int slot) +{ + return this_cpu_ptr(user_return_msrs)->values[slot].curr; +} +EXPORT_SYMBOL_GPL(kvm_get_user_return_msr); + static void drop_user_return_notifiers(void) { struct kvm_user_return_msrs *msrs =3D this_cpu_ptr(user_return_msrs); --=20 2.51.0.534.gc79095c0ca-goog From nobody Thu Oct 2 02:15:18 2025 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (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 DF5F4264A65 for ; Tue, 23 Sep 2025 15:37:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758641870; cv=none; b=DdDtRP+FEHbRDRD/avqnGcIteqP9Ybu5D9eF9A5L3+bmCLlmlNjy/REUn0kYVcNRCsn1pTNajom2QPYDDidUBFxev8Yp6ffC09mNMwA1LmbJmLFr6CovhYtvpmfSzrZVkmVC5zeq4MRvQfJ1+l7ItxbrTo8YWBxJVTVIolpP0nM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758641870; c=relaxed/simple; bh=B760xSwQfEWkIUiBDKXN2fQZyP0tDYOfoa377R5ElHk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=l+Rc65adHeo3zjHS5uR7jgtBUdNaawQPF6uy3jQ5LQehGMlEiuH0Qa5J36yO1LtfEYMm/sfUCLnlhGjBfwT6NFm/LcbyAFFSPwLE/Q+5Q8j6ThoHnVSTathWHPfPsWGQRf1TrOVX/kEtCb4sbRIj2T7NcOvX1FGUhM8GK/wv1BI= 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=yNOAllZQ; arc=none smtp.client-ip=209.85.214.201 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="yNOAllZQ" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-27c62320f16so16096875ad.1 for ; Tue, 23 Sep 2025 08:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1758641868; x=1759246668; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=eMZ5s15QgA1LUZtAao1CO2w7ujCiWNFlBED3uUB7s0I=; b=yNOAllZQF/f317VL46k2vqaZUIm+t1KqtKgaG2Ox57Ajk9vmWQ3Z+BnzVMnjvV9BmJ u1H/gBw7jiPVIJ7sn/lgGWrRp4LbBoGNP4drmHxeNKfzh45yOjMbik3vFP/10xOSAgQK /oNiUh2YUNrEkfPQUb36uAGSTGlvxXKbva6kpmoy56Is0Rl34KVQ4opG6XZMU8ARwXmp tHE8keum1ZAqt9ge/YxCLr/iKqy+j+8zHybcIuNLrP9/oB2ZQDE5bbBtfnSyBnypkTr8 FGcyctA0oHVqZuJMztUt3EK7Is/xh0D2/AANWW9qPhsuVWP66mGfZ+DknGNwciOXntDK gYEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758641868; x=1759246668; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eMZ5s15QgA1LUZtAao1CO2w7ujCiWNFlBED3uUB7s0I=; b=AmhNYAb3uCVdTAbC7kq2zv38KPa/Y11gEbTSOb2z+lJG3hELi2MoxLnNQT8Zb2hTqg stByhqktOCLktV/hPBd6k7SR9xcSSdrt7spu0+oZG73aLrLxvrNprZvWUnON496lT9jv 2vA1z2T3lK34wYmKu1XTVZEbDnGe4AsCQD/0MZijG1bn5hjBskuwZY86L9hvpAKELyca p9vM1piuFeMxdbzMIGPFcdnyIao60DujWJZ+L/kfb8BEwmqRz8X4Zm/6luf7xQimjqzf ZSW2i4ik4sT1tEwxursm1UD0xuHlp2nz6IoSXafBJL0lONgiNW6DsjZDNpZGGlNqb208 hueg== X-Forwarded-Encrypted: i=1; AJvYcCWFFKBso4YSFudrz2cmzXe3ZDoBPBDGDdQqm9zdkDN9H0RIWemSceVyqiGHNF2lUdP54C8TnwfGCGQJSrs=@vger.kernel.org X-Gm-Message-State: AOJu0YyfEcwCy0aDqOmFH0seYG9QLwnTNu2ym7Vkgyzgbw3G4FW/5ARm NSO+/vm5H2GzzS7LXeJjPHGYzqLOTU1Qa+UytwrPvT+w/HWzOSgYFla3LrZyPIchvhEhqNdX3S6 pjxihLw== X-Google-Smtp-Source: AGHT+IFuuXk4murZS4S1kiyk93K9qAop1IuBv5IVXqIopRy+jRfRnj6nw15yHZzr1S0Afco6H/UZC3PtVj0= X-Received: from plog5.prod.google.com ([2002:a17:902:8685:b0:269:7570:9ef0]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:ea05:b0:24c:cca1:7cfc with SMTP id d9443c01a7336-27ccaae76b4mr36812845ad.59.1758641867982; Tue, 23 Sep 2025 08:37:47 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 23 Sep 2025 08:37:38 -0700 In-Reply-To: <20250923153738.1875174-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250923153738.1875174-1-seanjc@google.com> X-Mailer: git-send-email 2.51.0.534.gc79095c0ca-goog Message-ID: <20250923153738.1875174-3-seanjc@google.com> Subject: [PATCH v3 2/2] KVM: SVM: Re-load current, not host, TSC_AUX on #VMEXIT from SEV-ES guest From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Hou Wenlong , Xiaoyao Li , Lai Jiangshan Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hou Wenlong Prior to running an SEV-ES guest, set TSC_AUX in the host save area to the current value in hardware, as tracked by the user return infrastructure, instead of always loading the host's desired value for the CPU. If the pCPU is also running a non-SEV-ES vCPU, loading the host's value on #VMEXIT could clobber the other vCPU's value, e.g. if the SEV-ES vCPU preempted the non-SEV-ES vCPU, in which case KVM expects the other vCPU's TSC_AUX value to be resident in hardware. Note, unlike TDX, which blindly _zeroes_ TSC_AUX on TD-Exit, SEV-ES CPUs can load an arbitrary value. Stuff the current value in the host save area instead of refreshing the user return cache so that KVM doesn't need to track whether or not the vCPU actually enterred the guest and thus loaded TSC_AUX from the host save area. Opportunistically tag tsc_aux_uret_slot as read-only after init to guard against unexpected modifications, and to make it obvious that using the variable in sev_es_prepare_switch_to_guest() is safe. Fixes: 916e3e5f26ab ("KVM: SVM: Do not use user return MSR support for virt= ualized TSC_AUX") Cc: stable@vger.kernel.org Suggested-by: Lai Jiangshan Signed-off-by: Hou Wenlong [sean: handle the SEV-ES case in sev_es_prepare_switch_to_guest()] Reviewed-by: Xiaoyao Li Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 10 ++++++++++ arch/x86/kvm/svm/svm.c | 25 ++++++------------------- arch/x86/kvm/svm/svm.h | 2 ++ 3 files changed, 18 insertions(+), 19 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index cce48fff2e6c..887d0d6ad856 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -4712,6 +4712,16 @@ void sev_es_prepare_switch_to_guest(struct vcpu_svm = *svm, struct sev_es_save_are hostsa->dr2_addr_mask =3D amd_get_dr_addr_mask(2); hostsa->dr3_addr_mask =3D amd_get_dr_addr_mask(3); } + + /* + * TSC_AUX is always virtualized for SEV-ES guests when the feature is + * available, i.e. TSC_AUX is loaded on #VMEXIT from the host save area. + * Set the save area to the current hardware value, i.e. the current + * user return value, so that the correct value is restored on #VMEXIT. + */ + if (cpu_feature_enabled(X86_FEATURE_V_TSC_AUX) && + !WARN_ON_ONCE(tsc_aux_uret_slot < 0)) + hostsa->tsc_aux =3D kvm_get_user_return_msr(tsc_aux_uret_slot); } =20 void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu *vcpu, u8 vector) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 67f4eed01526..0df2e1a5fb77 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -195,7 +195,7 @@ static DEFINE_MUTEX(vmcb_dump_mutex); * RDTSCP and RDPID are not used in the kernel, specifically to allow KVM = to * defer the restoration of TSC_AUX until the CPU returns to userspace. */ -static int tsc_aux_uret_slot __read_mostly =3D -1; +int tsc_aux_uret_slot __ro_after_init =3D -1; =20 static int get_npt_level(void) { @@ -577,18 +577,6 @@ static int svm_enable_virtualization_cpu(void) =20 amd_pmu_enable_virt(); =20 - /* - * If TSC_AUX virtualization is supported, TSC_AUX becomes a swap type - * "B" field (see sev_es_prepare_switch_to_guest()) for SEV-ES guests. - * Since Linux does not change the value of TSC_AUX once set, prime the - * TSC_AUX field now to avoid a RDMSR on every vCPU run. - */ - if (boot_cpu_has(X86_FEATURE_V_TSC_AUX)) { - u32 __maybe_unused msr_hi; - - rdmsr(MSR_TSC_AUX, sev_es_host_save_area(sd)->tsc_aux, msr_hi); - } - return 0; } =20 @@ -1406,10 +1394,10 @@ static void svm_prepare_switch_to_guest(struct kvm_= vcpu *vcpu) __svm_write_tsc_multiplier(vcpu->arch.tsc_scaling_ratio); =20 /* - * TSC_AUX is always virtualized for SEV-ES guests when the feature is - * available. The user return MSR support is not required in this case - * because TSC_AUX is restored on #VMEXIT from the host save area - * (which has been initialized in svm_enable_virtualization_cpu()). + * TSC_AUX is always virtualized (context switched by hardware) for + * SEV-ES guests when the feature is available. For non-SEV-ES guests, + * context switch TSC_AUX via the user_return MSR infrastructure (not + * all CPUs support TSC_AUX virtualization). */ if (likely(tsc_aux_uret_slot >=3D 0) && (!boot_cpu_has(X86_FEATURE_V_TSC_AUX) || !sev_es_guest(vcpu->kvm))) @@ -3004,8 +2992,7 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct = msr_data *msr) * TSC_AUX is always virtualized for SEV-ES guests when the * feature is available. The user return MSR support is not * required in this case because TSC_AUX is restored on #VMEXIT - * from the host save area (which has been initialized in - * svm_enable_virtualization_cpu()). + * from the host save area. */ if (boot_cpu_has(X86_FEATURE_V_TSC_AUX) && sev_es_guest(vcpu->kvm)) break; diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index 5d39c0b17988..bcbd651d04f2 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -52,6 +52,8 @@ extern bool x2avic_enabled; extern bool vnmi; extern int lbrv; =20 +extern int tsc_aux_uret_slot __ro_after_init; + /* * Clean bits in VMCB. * VMCB_ALL_CLEAN_MASK might also need to --=20 2.51.0.534.gc79095c0ca-goog