Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp220825pxj; Tue, 18 May 2021 01:40:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfpbXJVmoMmC9KYz0/UvZ8mGWrd8kKZmRRKCiTcVQmeOaer62W2Uiu3sIOQntmo2SxSllB X-Received: by 2002:a05:6e02:eac:: with SMTP id u12mr3374623ilj.177.1621327249384; Tue, 18 May 2021 01:40:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621327249; cv=none; d=google.com; s=arc-20160816; b=xH2TDkeXK8e7v+bgnkMHQwGeC+jkvwABEuf8f5yBhvUIjNh1qg4XD5ZStF5xXe8p4M uYcEuM0/eelxc1h9dSmCO3hVLrTnn6W8i3xl48JvHCaliYrqJMFrFKin+cNX0u3HM+VP Iq6gDR86kNa7/+SbpBUFglHbPTFWeD0CGot19/XqpbWt1DwPCGlqH+nep2iIcVgx3AxM tSf0pIYFAYQYa+RD0OptRiO+G1fi3A7zehwT6tn05Tv/LB+xd86EYYXDSR06FPZPl4Mh pWFY6J6IhgTMn0H5FjDOKylG13ANFT65Oh3mxBLwSi5RzM/BIjSE5sw8wkW+82satzfh s2fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=wER7KXuR0KnkrgtzFPq7qjZSxZsUYUavfmaUFjUYxTo=; b=AMT9NyjCxUAvVg0dU83SPRE9xdPGAGVkC3/DI9/bFUJrreINEWBj6QibB0tJzzhIyc TBTQgB1Zvedqi6sRLXy7pXLBsJZL7kI/T9cEopb7AJmv43KWmuoLjbZChPCxuVlU39fI xmw9qN+feAeXgX9Q+Iy/WEJHJtFYULbPCb0PLVwgZm1Qtg8o4MGYBv9ehsCi6ixgrS/6 8sBF2eEaxR/x46oyFzTxHpLnOUe66a56r2bADz7YqAB+jl8VTGuQqo/vErvzBuPhjmdo BWM0NQPeDaiWFnq/2hpOvNuHAxwAH8TED41S4+WMJpcLC+QD8uW+RiNYtfw+Rcc2Ng+o +QRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DASroyqK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b9si21100637ior.14.2021.05.18.01.40.36; Tue, 18 May 2021 01:40:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DASroyqK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240971AbhEQPCX (ORCPT + 99 others); Mon, 17 May 2021 11:02:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:48080 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241566AbhEQOwA (ORCPT ); Mon, 17 May 2021 10:52:00 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3EBD961988; Mon, 17 May 2021 14:23:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1621261425; bh=gHSj6tyoz1bH7DPcjnPJnj511RmRmxNiZ5alo7SwcLA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DASroyqKHgCMFym1qO9y+HADBinZpJ9uji33Mcx9dFbpgIZIlL2+be7rHP2dhH4b8 z5WXIqm4Bo20nBgzwx35HtodixC/tnAmD3mpgn6I7li5aff1+ooHRCyY5D/DTQ4yLY pzGE/3tXpP5DE3e84/ZKt19UDtNYKI0lFjKQ3pPw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Reiji Watanabe , Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.12 331/363] KVM: x86: Add support for RDPID without RDTSCP Date: Mon, 17 May 2021 16:03:17 +0200 Message-Id: <20210517140313.798043158@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210517140302.508966430@linuxfoundation.org> References: <20210517140302.508966430@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sean Christopherson commit 36fa06f9ff39f23e03cd8206dc6bbb7711c23be6 upstream. Allow userspace to enable RDPID for a guest without also enabling RDTSCP. Aside from checking for RDPID support in the obvious flows, VMX also needs to set ENABLE_RDTSCP=1 when RDPID is exposed. For the record, there is no known scenario where enabling RDPID without RDTSCP is desirable. But, both AMD and Intel architectures allow for the condition, i.e. this is purely to make KVM more architecturally accurate. Fixes: 41cd02c6f7f6 ("kvm: x86: Expose RDPID in KVM_GET_SUPPORTED_CPUID") Cc: stable@vger.kernel.org Reported-by: Reiji Watanabe Signed-off-by: Sean Christopherson Message-Id: <20210504171734.1434054-8-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman --- arch/x86/kvm/svm/svm.c | 6 ++++-- arch/x86/kvm/vmx/vmx.c | 27 +++++++++++++++++++++++---- arch/x86/kvm/x86.c | 3 ++- 3 files changed, 29 insertions(+), 7 deletions(-) --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -2741,7 +2741,8 @@ static int svm_get_msr(struct kvm_vcpu * if (!boot_cpu_has(X86_FEATURE_RDTSCP)) return 1; if (!msr_info->host_initiated && - !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP)) + !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP) && + !guest_cpuid_has(vcpu, X86_FEATURE_RDPID)) return 1; msr_info->data = svm->tsc_aux; break; @@ -2952,7 +2953,8 @@ static int svm_set_msr(struct kvm_vcpu * return 1; if (!msr->host_initiated && - !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP)) + !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP) && + !guest_cpuid_has(vcpu, X86_FEATURE_RDPID)) return 1; /* --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -1734,7 +1734,8 @@ static void setup_msrs(struct vcpu_vmx * if (update_transition_efer(vmx)) vmx_setup_uret_msr(vmx, MSR_EFER); - if (guest_cpuid_has(&vmx->vcpu, X86_FEATURE_RDTSCP)) + if (guest_cpuid_has(&vmx->vcpu, X86_FEATURE_RDTSCP) || + guest_cpuid_has(&vmx->vcpu, X86_FEATURE_RDPID)) vmx_setup_uret_msr(vmx, MSR_TSC_AUX); vmx_setup_uret_msr(vmx, MSR_IA32_TSX_CTRL); @@ -1933,7 +1934,8 @@ static int vmx_get_msr(struct kvm_vcpu * break; case MSR_TSC_AUX: if (!msr_info->host_initiated && - !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP)) + !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP) && + !guest_cpuid_has(vcpu, X86_FEATURE_RDPID)) return 1; goto find_uret_msr; case MSR_IA32_DEBUGCTLMSR: @@ -2230,7 +2232,8 @@ static int vmx_set_msr(struct kvm_vcpu * break; case MSR_TSC_AUX: if (!msr_info->host_initiated && - !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP)) + !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP) && + !guest_cpuid_has(vcpu, X86_FEATURE_RDPID)) return 1; /* Check reserved bit, higher 32 bits should be zero */ if ((data >> 32) != 0) @@ -4302,7 +4305,23 @@ static void vmx_compute_secondary_exec_c xsaves_enabled, false); } - vmx_adjust_sec_exec_feature(vmx, &exec_control, rdtscp, RDTSCP); + /* + * RDPID is also gated by ENABLE_RDTSCP, turn on the control if either + * feature is exposed to the guest. This creates a virtualization hole + * if both are supported in hardware but only one is exposed to the + * guest, but letting the guest execute RDTSCP or RDPID when either one + * is advertised is preferable to emulating the advertised instruction + * in KVM on #UD, and obviously better than incorrectly injecting #UD. + */ + if (cpu_has_vmx_rdtscp()) { + bool rdpid_or_rdtscp_enabled = + guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP) || + guest_cpuid_has(vcpu, X86_FEATURE_RDPID); + + vmx_adjust_secondary_exec_control(vmx, &exec_control, + SECONDARY_EXEC_ENABLE_RDTSCP, + rdpid_or_rdtscp_enabled, false); + } vmx_adjust_sec_exec_feature(vmx, &exec_control, invpcid, INVPCID); vmx_adjust_sec_exec_exiting(vmx, &exec_control, rdrand, RDRAND); --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5864,7 +5864,8 @@ static void kvm_init_msr_list(void) continue; break; case MSR_TSC_AUX: - if (!kvm_cpu_cap_has(X86_FEATURE_RDTSCP)) + if (!kvm_cpu_cap_has(X86_FEATURE_RDTSCP) && + !kvm_cpu_cap_has(X86_FEATURE_RDPID)) continue; break; case MSR_IA32_UMWAIT_CONTROL: