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

Re: [Xen-devel] [PATCH] x86/svm: Drop svm_vm{load,save}() helpers


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: "Woods, Brian" <Brian.Woods@xxxxxxx>
  • Date: Fri, 28 Jun 2019 15:59:31 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; test.office365.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=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=66av14pKHRIAiAi9DzeV+nGkJ59K/0olHF5/pDUdRWI=; b=ApA2nez5lFF500w4Fhl9FciTqcCqUmBqiFIcGBivevz8YnxmegoUWO0PRye5/PxfchzEYSzeYcUGMwz5XuXbvv/ybiu8B/7/FoqdznXJCWViw0PuQYBUqAqqsT66rMGP1Ix0Yef/HvVwI0NbHacBMxmGp+3p+G3O81ZmznY8BuA=
  • Arc-seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=wCiN2gQoak8saq1+KWjEgY0PbHBSaBVq+hhjBxdMASba4xGo/E4XMCqejR0aLd6+tEeMOPY5Yob8oeJFO1YpUQai7vtI28Wuhy0UieWzASmiMYCRompaNXL/fpr+8EAHHQSuvXQkSs3N+o97nV8D95/bJcqvQ738m3TTjJ6FarM=
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Woods@xxxxxxx;
  • Cc: Jan Beulich <JBeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, "Suthikulpanit, Suravee" <Suravee.Suthikulpanit@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, "Woods, Brian" <Brian.Woods@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 28 Jun 2019 15:59:45 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVJ2Ca5PkM0pibh0SK+JriWeVAr6axRiwA
  • Thread-topic: [PATCH] x86/svm: Drop svm_vm{load,save}() helpers

On Thu, Jun 20, 2019 at 01:06:21PM +0100, Andy Cooper wrote:
> Following on from c/s 7d161f6537 "x86/svm: Fix svm_vmcb_dump() when used in
> current context", there is now only a single user of svm_vmsave() remaining in
> the tree, with all users moved to svm_vm{load,save}_pa().
> 
> nv->nv_n1vmcx has a matching nv->nv_n1vmcx_pa which is always correct, and
> avoids a redundant __pa() translation behind the scenes.
> 
> With this gone, all VM{LOAD,SAVE} operations are using paddr_t's which is more
> efficient, so drop the svm_vm{load,save}() helpers to avoid uses of them
> reappearing in the future.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Acked-by: Brian Woods <brian.woods@xxxxxxx>

> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Wei Liu <wl@xxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
> CC: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
> CC: Brian Woods <brian.woods@xxxxxxx>
> 
> It turns out I was mistaken about how complicated this was.
> ---
>  xen/arch/x86/hvm/svm/nestedsvm.c  | 2 +-
>  xen/include/asm-x86/hvm/svm/svm.h | 3 ---
>  2 files changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c 
> b/xen/arch/x86/hvm/svm/nestedsvm.c
> index 35c1a04..fef124f 100644
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -1030,7 +1030,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct 
> cpu_user_regs *regs)
>      struct vmcb_struct *ns_vmcb = nv->nv_vvmcx;
>      struct vmcb_struct *n2vmcb = nv->nv_n2vmcx;
>  
> -    svm_vmsave(nv->nv_n1vmcx);
> +    svm_vmsave_pa(nv->nv_n1vmcx_pa);
>  
>      /* Cache guest physical address of virtual vmcb
>       * for VMCB Cleanbit emulation.
> diff --git a/xen/include/asm-x86/hvm/svm/svm.h 
> b/xen/include/asm-x86/hvm/svm/svm.h
> index 6e688a8..16a994e 100644
> --- a/xen/include/asm-x86/hvm/svm/svm.h
> +++ b/xen/include/asm-x86/hvm/svm/svm.h
> @@ -22,9 +22,6 @@
>  
>  #include <xen/types.h>
>  
> -#define svm_vmload(x)     svm_vmload_pa(__pa(x))
> -#define svm_vmsave(x)     svm_vmsave_pa(__pa(x))
> -
>  static inline void svm_vmload_pa(paddr_t vmcb)
>  {
>      asm volatile (
> -- 
> 2.1.4
> 

-- 
Brian Woods

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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