[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 7/9] x86/svm: VMEntry/Exit logic for MSR_SPEC_CTRL


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 1 Feb 2022 12:47:34 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pDwqnYfO5PggWep5MSjL+lELl+vzJJSRyHeY63WURWQ=; b=O/qTIWf59p+hMGGeoQk1MAiTlAMsyvejWMyWP385WXygDEZrOAzQ954P/GnYsF6y6jONRnd2nXfSte2Yx6gg3Il/h/UFlyqFPneMA5eQJ0nh5/NO4zcKZDO+2fkGmSCdawmJb/+nuGWg5XsOY97CEzLVyqOPnxEtWa1bnL6D2Ca3LIwdj/ryFcCkhbdqgRaHK0aaZwiOgsEXf2DCrji0nkwwZoWuNG2dF1cTA/OgeU28gsszE05axUztzDGGSmiCs4KkL9CEDOx7Xpv7XZlGTahmV2GBlA/iqHc4wM5yQ2Sfu00QFeXRGAsYSiFkYZaRIDIDp0IP3x25hYMHouvNcA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JzCAtJ48EfBzo9eIqR/JYntWrfxY7kS8tiMWL072rLKpG5GlCVshLwN9Ojm8r1VDRS/jhEgsH9PbWI7OyEGEvbFRH2AUobgRpPVRH+CzourXnRiBBAbvkHYADzyyMrXtHEsuaFdp0jajApl7OvQ8szWNr4BUt9A5omdeDoJJ9WrotBtXFh43Mqw9c/RIpAoPV2D+upaNcwf04J7bbHAcrbxjx/ncRBz2U/qrwH6SeWUznjb9ZJ2q8GMgDzJThDM9M8S1k+QQK6ATWQY8AhaM2tszN9PrVMh+zU3E7ZN0jwnW9+hoY4BIlvH/WVLeCmdByHzirfmlIj3DIVTYYnwTrQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 01 Feb 2022 11:47:46 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 31.01.2022 16:36, Andrew Cooper wrote:
> Hardware maintains both host and guest versions of MSR_SPEC_CTRL, but guests
> run with the logical OR of both values.  Therefore, in principle we want to
> clear Xen's value before entering the guest.  However, for migration
> compatibility,

I think you've explained this to me before, but I can't seem to put
all of it together already now. Could expand on how a non-zero value
behind a guest's back can help with migration compatibility? At the
first glance I would be inclined to say only what the guest actually
gets to see and use can affect its migration.

> and for performance reasons with SEV-SNP guests, we want the
> ability to use a nonzero value behind the guest's back.  Use vcpu_msrs to hold
> this value, with the guest value in the VMCB.
> 
> On the VMEntry path, adjusting MSR_SPEC_CTRL must be done after CLGI so as to
> be atomic with respect to NMIs/etc.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Preferably with the above expansion and with one further style
issue (see below) taken care of
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

> --- a/xen/arch/x86/hvm/svm/entry.S
> +++ b/xen/arch/x86/hvm/svm/entry.S
> @@ -55,11 +55,23 @@ __UNLIKELY_END(nsvm_hap)
>          mov  %rsp, %rdi
>          call svm_vmenter_helper
>  
> -        mov VCPU_arch_msrs(%rbx), %rax
> -        mov VCPUMSR_spec_ctrl_raw(%rax), %eax
> +        clgi
>  
>          /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
> -        /* SPEC_CTRL_EXIT_TO_SVM   (nothing currently) */
> +        /* SPEC_CTRL_EXIT_TO_SVM       Req: b=curr %rsp=regs/cpuinfo, Clob: 
> acd */
> +        .macro svm_vmentry_spec_ctrl
> +            mov    VCPU_arch_msrs(%rbx), %rax
> +            movzbl CPUINFO_last_spec_ctrl(%rsp), %edx
> +            mov    VCPUMSR_spec_ctrl_raw(%rax), %eax
> +            cmp    %edx, %eax
> +            je 1f  /* Skip write if value is correct. */

Wold you mind padding the insn operand properly, in line with all
others nearby?

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.