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.coop...@citrix.com>
---
CC: Jan Beulich <jbeul...@suse.com>
CC: Wei Liu <w...@xen.org>
CC: Roger Pau Monné <roger....@citrix.com>
CC: Boris Ostrovsky <boris.ostrov...@oracle.com>
CC: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>
CC: Brian Woods <brian.wo...@amd.com>
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
