On 21/09/17 17:00, Boris Ostrovsky wrote:
Signed-off-by: Juergen Gross <jgr...@suse.com>
---
arch/x86/include/asm/xen/page.h | 11 ++++++++++-
arch/x86/xen/mmu_pv.c | 4 ++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/xen/page.h
b/arch/x86/include/asm/xen/page.h
index 07b6531813c4..bcb8b193c8d1 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -26,6 +26,15 @@ typedef struct xpaddr {
phys_addr_t paddr;
} xpaddr_t;
+#ifdef CONFIG_X86_64
+#define XEN_PHYSICAL_MASK ((1UL << 52) - 1)
SME is not supported for PV guests but for consistency (and in case sme
bit somehow gets set)
#define XEN_PHYSICAL_MASK __sme_clr(((1UL << 52) - 1))
Hmm, really? Shouldn't we rather add something like
BUG_ON(sme_active());
somewhere?
We can do that too.
Please don't do anything to cause Linux to crash if Xen is using SME
itself, but leaving all of the PV guest unencrypted.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel