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;
Date:   Mon, 7 Dec 2020 15:13:15 -0800
From:   Sean Christopherson <seanjc@google.com>
To:     Babu Moger <babu.moger@amd.com>
Cc:     pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com,
        bp@alien8.de, fenghua.yu@intel.com, tony.luck@intel.com,
        wanpengli@tencent.com, kvm@vger.kernel.org,
        thomas.lendacky@amd.com, peterz@infradead.org, joro@8bytes.org,
        x86@kernel.org, kyung.min.park@intel.com,
        linux-kernel@vger.kernel.org, krish.sadhukhan@oracle.com,
        hpa@zytor.com, mgross@linux.intel.com, vkuznets@redhat.com,
        kim.phillips@amd.com, wei.huang2@amd.com, jmattson@google.com
Subject: Re: [PATCH 2/2] KVM: SVM: Add support for Virtual SPEC_CTRL
Message-ID: <X863C6ikshtMHemk@google.com>
References: <160738054169.28590.5171339079028237631.stgit@bmoger-ubuntu>
 <160738067970.28590.1275116532320186155.stgit@bmoger-ubuntu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <160738067970.28590.1275116532320186155.stgit@bmoger-ubuntu>
Precedence: bulk

On Mon, Dec 07, 2020, Babu Moger wrote:
> Newer AMD processors have a feature to virtualize the use of the
> SPEC_CTRL MSR. When supported, the SPEC_CTRL MSR is automatically
> virtualized and no longer requires hypervisor intervention.

Hrm, is MSR_AMD64_VIRT_SPEC_CTRL only for SSBD?  Should that MSR be renamed to
avoid confusion with the new form of VIRT_SPEC_CTRL?

> This feature is detected via CPUID function 0x8000000A_EDX[20]:
> GuestSpecCtrl.
> 
> Hypervisors are not required to enable this feature since it is
> automatically enabled on processors that support it.
> 
> When this feature is enabled, the hypervisor no longer has to
> intercept the usage of the SPEC_CTRL MSR and no longer is required to
> save and restore the guest SPEC_CTRL setting when switching
> hypervisor/guest modes.

Well, it's still required if the hypervisor wanted to allow the guest to turn
off mitigations that are enabled in the host.  I'd omit this entirely and focus
on what hardware does and how Linux/KVM utilize the new feature.

> The effective SPEC_CTRL setting is the guest SPEC_CTRL setting or'ed with the
> hypervisor SPEC_CTRL setting. 

This line needs to be higher in the changelog, it's easily the most relevant
info for understanding the mechanics.  Please also explicitly state the context
switching mechanics, e.g. is it tracked in the VMCB, loaded on VMRUN, saved on
VM-Exit, etc...

> This allows the hypervisor to ensure a minimum SPEC_CTRL if desired.
>
> This support also fixes an issue where a guest may sometimes see an
> inconsistent value for the SPEC_CTRL MSR on processors that support
> this feature. With the current SPEC_CTRL support, the first write to
> SPEC_CTRL is intercepted and the virtualized version of the SPEC_CTRL
> MSR is not updated. When the guest reads back the SPEC_CTRL MSR, it
> will be 0x0, instead of the actual expected value. There isn’t a
> security concern here, because the host SPEC_CTRL value is or’ed with
> the Guest SPEC_CTRL value to generate the effective SPEC_CTRL value.
> KVM writes with the guest's virtualized SPEC_CTRL value to SPEC_CTRL
> MSR just before the VMRUN, so it will always have the actual value
> even though it doesn’t appear that way in the guest. The guest will
> only see the proper value for the SPEC_CTRL register if the guest was
> to write to the SPEC_CTRL register again. With Virtual SPEC_CTRL
> support, the MSR interception of SPEC_CTRL is disabled during
> vmcb_init, so this will no longer be an issue.
> 
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
>  arch/x86/kvm/svm/svm.c |   17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 79b3a564f1c9..3d73ec0cdb87 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -1230,6 +1230,14 @@ static void init_vmcb(struct vcpu_svm *svm)
>  
>  	svm_check_invpcid(svm);
>  
> +	/*
> +	 * If the host supports V_SPEC_CTRL then disable the interception
> +	 * of MSR_IA32_SPEC_CTRL.
> +	 */
> +	if (boot_cpu_has(X86_FEATURE_V_SPEC_CTRL))
> +		set_msr_interception(&svm->vcpu, svm->msrpm, MSR_IA32_SPEC_CTRL,
> +				     1, 1);
> +
>  	if (kvm_vcpu_apicv_active(&svm->vcpu))
>  		avic_init_vmcb(svm);
>  
> @@ -3590,7 +3598,8 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu)
>  	 * is no need to worry about the conditional branch over the wrmsr
>  	 * being speculatively taken.
>  	 */
> -	x86_spec_ctrl_set_guest(svm->spec_ctrl, svm->virt_spec_ctrl);
> +	if (!static_cpu_has(X86_FEATURE_V_SPEC_CTRL))
> +		x86_spec_ctrl_set_guest(svm->spec_ctrl, svm->virt_spec_ctrl);
>  
>  	svm_vcpu_enter_exit(vcpu, svm);
>  
> @@ -3609,12 +3618,14 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu)
>  	 * If the L02 MSR bitmap does not intercept the MSR, then we need to
>  	 * save it.
>  	 */
> -	if (unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)))
> +	if (!static_cpu_has(X86_FEATURE_V_SPEC_CTRL) &&
> +	    unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)))

This will break migration, or maybe just cause wierdness, as userspace will
always see '0' when reading SPEC_CTRL and its writes will be ignored.  Is there
a VMCB field that holds the guest's value?  If so, this read can be skipped, and
instead the MSR set/get flows probably need to poke into the VMCB.

>  		svm->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL);
>  
>  	reload_tss(vcpu);
>  
> -	x86_spec_ctrl_restore_host(svm->spec_ctrl, svm->virt_spec_ctrl);
> +	if (!static_cpu_has(X86_FEATURE_V_SPEC_CTRL))
> +		x86_spec_ctrl_restore_host(svm->spec_ctrl, svm->virt_spec_ctrl);
>  
>  	vcpu->arch.cr2 = svm->vmcb->save.cr2;
>  	vcpu->arch.regs[VCPU_REGS_RAX] = svm->vmcb->save.rax;
>