From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751797AbdIUTBP (ORCPT ); Thu, 21 Sep 2017 15:01:15 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:27540 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751700AbdIUTBN (ORCPT ); Thu, 21 Sep 2017 15:01:13 -0400 Subject: Re: [Xen-devel] [PATCH] xen: support 52 bit physical addresses in pv guests To: Andrew Cooper , Juergen Gross , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Cc: kirill.shutemov@linux.intel.com References: <20170921080138.22917-1-jgross@suse.com> <287fb059-910e-4dc9-b21d-581c97a06323@oracle.com> <7fa7aa6d-6458-0d86-83a4-b3b6daebfa80@citrix.com> From: Boris Ostrovsky Message-ID: Date: Thu, 21 Sep 2017 15:01:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7fa7aa6d-6458-0d86-83a4-b3b6daebfa80@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/21/2017 12:16 PM, Andrew Cooper wrote: > On 21/09/17 17:00, Boris Ostrovsky wrote: >> >>> >>>> >>>>> >>>>> Signed-off-by: Juergen Gross >>>>> --- >>>>>    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. sme_active() returns true if the *guest* enables it. Also, if the guest's memory is unencrypted, doesn't this mean that mfns that it sees (or, rather, ptes) will not have the SME bit set? -boris