Received: by 10.223.176.5 with SMTP id f5csp630084wra; Sat, 3 Feb 2018 06:59:01 -0800 (PST) X-Google-Smtp-Source: AH8x227lVoXlqMAb1LW92nDOgrng0ZISmsCopu+38Xmlu1iG8ampY2toMdxM5gy9P0Cm3HYSggAv X-Received: by 2002:a17:902:7889:: with SMTP id q9-v6mr17847536pll.114.1517669941685; Sat, 03 Feb 2018 06:59:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517669941; cv=none; d=google.com; s=arc-20160816; b=uSsJMIkOZ4jsDOmpolJY00qLs5giTq7uS/5qEnFq3vcEGc33t1BZLbfGYWNDFwhFFs Gq0ClnnMxMiJy5ZFdz5KBd20h8Bv+4iUj/8pGl1pp5IXPy1iHmyWBKsYH5aUlAXTATZX qiIyDgNoQEewkaWIfqrU1Y3nU1yKtGPETUdf9bZE2CRloZchuHuMEcjqVqZfqfRyaJew mIb6MnY286i4Eiab4SHTenCpadfC1sWIwNONGyTRQPowhlgrXlVU+auvz+haSlU0KIAM wsb+GqJ73hiDNbvh2d3bGU7/H47M31aGk98Q0IrOzQBQNg7e3djg3Baa3gTF6gcKa67i vtsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=pu0s0JEkMnW51X+naLOlvQYMwM2aGRQhg9Uzg7K7HvY=; b=oxbSMI0Sk5iDtjawH2puZCb49zD7m9vs+AKroT+TsgRjVDkvOCQHlISehhZRCS7syp 4gAjwL+m34/BrYKYZKxTlhd5qakXbCo+EUlhFHpyaLeSJJITAVCvVMhDf409j9zIfxi+ 8MvGrgr+ELG+P0SpW21h4LpnJ0fLWjxYiSyfKDHL47P7n8wQiog9uPLGRNJ32q+mtEmA y5UPJAeIv5Fre9CRpQfnpVKIH+wJ2fqWBgCQFmnm/fegJtgieXG5m95Zn1VPLpBNEUPM zY9K6KcvCMgHboolVl5dx5Dq7OVxfXKAh0BwAXi8PCu6ARP7hLcKhVeytL/RtLOcK+DO O8EA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazon.de header.s=amazon201209 header.b=rQqrhJL4; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q11si732054pgc.165.2018.02.03.06.58.45; Sat, 03 Feb 2018 06:59:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amazon.de header.s=amazon201209 header.b=rQqrhJL4; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752236AbeBCO4y (ORCPT + 99 others); Sat, 3 Feb 2018 09:56:54 -0500 Received: from smtp-fw-9102.amazon.com ([207.171.184.29]:59056 "EHLO smtp-fw-9102.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751638AbeBCO4s (ORCPT ); Sat, 3 Feb 2018 09:56:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1517669808; x=1549205808; h=from:to:cc:subject:date:message-id; bh=pu0s0JEkMnW51X+naLOlvQYMwM2aGRQhg9Uzg7K7HvY=; b=rQqrhJL4Dgas5XPhI2YHqMPOIL3SRrxW5pKK6efPWzVAa3XiNGMxZKFE Ofxa2kOU2xKkWIiwVe49JdQxMEo8ZLQW/MNEYXCB/2tVz5v8eZ6nTqow8 HBwtMWbHkT/wIGFXwF0h2kAbjOYX9LFy7IJLV3CQr4SQ5PRDERiyFv/zh A=; X-IronPort-AV: E=Sophos;i="5.46,454,1511827200"; d="scan'208";a="592757908" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1a-16acd5e0.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2018 14:56:45 +0000 Received: from u54e1ad5160425a4b64ea.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com [10.0.103.146]) by email-inbound-relay-1a-16acd5e0.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w13EuYbx022847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Feb 2018 14:56:38 GMT Received: from u54e1ad5160425a4b64ea.ant.amazon.com (localhost [127.0.0.1]) by u54e1ad5160425a4b64ea.ant.amazon.com (8.15.2/8.15.2/Debian-3) with ESMTP id w13EuWsO020897; Sat, 3 Feb 2018 15:56:32 +0100 Received: (from karahmed@localhost) by u54e1ad5160425a4b64ea.ant.amazon.com (8.15.2/8.15.2/Submit) id w13EuT8x020893; Sat, 3 Feb 2018 15:56:29 +0100 From: KarimAllah Ahmed To: linux-kernel@vger.kernel.org, x86@kernel.org, kvm@vger.kernel.org Cc: KarimAllah Ahmed , Asit Mallick , Arjan Van De Ven , Dave Hansen , Andi Kleen , Andrea Arcangeli , Linus Torvalds , Tim Chen , Thomas Gleixner , Dan Williams , Jun Nakajima , Paolo Bonzini , David Woodhouse , Greg KH , Andy Lutomirski , Ashok Raj Subject: [PATCH v7] KVM: SVM: Allow direct access to MSR_IA32_SPEC_CTRL Date: Sat, 3 Feb 2018 15:56:23 +0100 Message-Id: <1517669783-20732-1-git-send-email-karahmed@amazon.de> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ Based on a patch from Paolo Bonzini ] ... basically doing exactly what we do for VMX: - Passthrough SPEC_CTRL to guests (if enabled in guest CPUID) - Save and restore SPEC_CTRL around VMExit and VMEntry only if the guest actually used it. Cc: Asit Mallick Cc: Arjan Van De Ven Cc: Dave Hansen Cc: Andi Kleen Cc: Andrea Arcangeli Cc: Linus Torvalds Cc: Tim Chen Cc: Thomas Gleixner Cc: Dan Williams Cc: Jun Nakajima Cc: Paolo Bonzini Cc: David Woodhouse Cc: Greg KH Cc: Andy Lutomirski Cc: Ashok Raj Signed-off-by: KarimAllah Ahmed Signed-off-by: David Woodhouse --- v6: - ditch save_spec_ctrl_on_exit in favor of msr_write_intercepted v5: - Add SPEC_CTRL to direct_access_msrs. --- arch/x86/kvm/svm.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 254eefb..4e3c795 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -184,6 +184,8 @@ struct vcpu_svm { u64 gs_base; } host; + u64 spec_ctrl; + u32 *msrpm; ulong nmi_iret_rip; @@ -249,6 +251,7 @@ static const struct svm_direct_access_msrs { { .index = MSR_CSTAR, .always = true }, { .index = MSR_SYSCALL_MASK, .always = true }, #endif + { .index = MSR_IA32_SPEC_CTRL, .always = false }, { .index = MSR_IA32_PRED_CMD, .always = false }, { .index = MSR_IA32_LASTBRANCHFROMIP, .always = false }, { .index = MSR_IA32_LASTBRANCHTOIP, .always = false }, @@ -882,6 +885,25 @@ static bool valid_msr_intercept(u32 index) return false; } +static bool msr_write_intercepted(struct kvm_vcpu *vcpu, unsigned msr) +{ + u8 bit_write; + unsigned long tmp; + u32 offset; + u32 *msrpm; + + msrpm = is_guest_mode(vcpu) ? to_svm(vcpu)->nested.msrpm: + to_svm(vcpu)->msrpm; + + offset = svm_msrpm_offset(msr); + bit_write = 2 * (msr & 0x0f) + 1; + tmp = msrpm[offset]; + + BUG_ON(offset == MSR_INVALID); + + return !!test_bit(bit_write, &tmp); +} + static void set_msr_interception(u32 *msrpm, unsigned msr, int read, int write) { @@ -1584,6 +1606,8 @@ static void svm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) u32 dummy; u32 eax = 1; + svm->spec_ctrl = 0; + if (!init_event) { svm->vcpu.arch.apic_base = APIC_DEFAULT_PHYS_BASE | MSR_IA32_APICBASE_ENABLE; @@ -3605,6 +3629,13 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) case MSR_VM_CR: msr_info->data = svm->nested.vm_cr_msr; break; + case MSR_IA32_SPEC_CTRL: + if (!msr_info->host_initiated && + !guest_cpuid_has(vcpu, X86_FEATURE_IBRS)) + return 1; + + msr_info->data = svm->spec_ctrl; + break; case MSR_IA32_UCODE_REV: msr_info->data = 0x01000065; break; @@ -3696,6 +3727,33 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr) case MSR_IA32_TSC: kvm_write_tsc(vcpu, msr); break; + case MSR_IA32_SPEC_CTRL: + if (!msr->host_initiated && + !guest_cpuid_has(vcpu, X86_FEATURE_IBRS)) + return 1; + + /* The STIBP bit doesn't fault even if it's not advertised */ + if (data & ~(SPEC_CTRL_IBRS | SPEC_CTRL_STIBP)) + return 1; + + svm->spec_ctrl = data; + + if (!data) + break; + + /* + * For non-nested: + * When it's written (to non-zero) for the first time, pass + * it through. + * + * For nested: + * The handling of the MSR bitmap for L2 guests is done in + * nested_svm_vmrun_msrpm. + * We update the L1 MSR bit as well since it will end up + * touching the MSR anyway now. + */ + set_msr_interception(svm->msrpm, MSR_IA32_SPEC_CTRL, 1, 1); + break; case MSR_IA32_PRED_CMD: if (!msr->host_initiated && !guest_cpuid_has(vcpu, X86_FEATURE_IBPB)) @@ -4964,6 +5022,15 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) local_irq_enable(); + /* + * If this vCPU has touched SPEC_CTRL, restore the guest's value if + * it's non-zero. Since vmentry is serialising on affected CPUs, there + * is no need to worry about the conditional branch over the wrmsr + * being speculatively taken. + */ + if (svm->spec_ctrl) + wrmsrl(MSR_IA32_SPEC_CTRL, svm->spec_ctrl); + asm volatile ( "push %%" _ASM_BP "; \n\t" "mov %c[rbx](%[svm]), %%" _ASM_BX " \n\t" @@ -5056,6 +5123,27 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) #endif ); + /* + * We do not use IBRS in the kernel. If this vCPU has used the + * SPEC_CTRL MSR it may have left it on; save the value and + * turn it off. This is much more efficient than blindly adding + * it to the atomic save/restore list. Especially as the former + * (Saving guest MSRs on vmexit) doesn't even exist in KVM. + * + * For non-nested case: + * If the L01 MSR bitmap does not intercept the MSR, then we need to + * save it. + * + * For nested case: + * If the L02 MSR bitmap does not intercept the MSR, then we need to + * save it. + */ + if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)) + rdmsrl(MSR_IA32_SPEC_CTRL, svm->spec_ctrl); + + if (svm->spec_ctrl) + wrmsrl(MSR_IA32_SPEC_CTRL, 0); + /* Eliminate branch target predictions from guest mode */ vmexit_fill_RSB(); -- 2.7.4