Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751872AbdIUQBD (ORCPT ); Thu, 21 Sep 2017 12:01:03 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:21265 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751745AbdIUQBB (ORCPT ); Thu, 21 Sep 2017 12:01:01 -0400 Subject: Re: [PATCH] xen: support 52 bit physical addresses in pv guests To: 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> From: Boris Ostrovsky Message-ID: Date: Thu, 21 Sep 2017 12:00:49 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2507 Lines: 80 On 09/21/2017 10:41 AM, Juergen Gross wrote: > On 21/09/17 16:14, Boris Ostrovsky wrote: >> >> >> On 09/21/2017 04:01 AM, Juergen Gross wrote: >>> Physical addresses on processors supporting 5 level paging can be up to >>> 52 bits wide. For a Xen pv guest running on such a machine those >>> physical addresses have to be supported in order to be able to use any >>> memory on the machine even if the guest itself does not support 5 level >>> paging. >>> >>> So when reading/writing a MFN from/to a pte don't use the kernel's >>> PTE_PFN_MASK but a new XEN_PTE_MFN_MASK allowing full 40 bit wide MFNs. >> >> full 52 bits? > > The MFN mask is only 40 bits. This plus the 12 bits page offset are 52 > bits of machine address width. Oh, right --- frames, not addresses. > >> >>> >>> 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. > >> But the real question that I have is whether this patch is sufficient. >> We are trying to preserve more bits in mfn but then this mfn is used, >> say, in pte_pfn_to_mfn() to build a pte. Can we be sure that the pte >> won't be stripped of higher bits in native code (again, as an example, >> native_make_pte()) because we are compiled with 5LEVEL? > > native_make_pte() just encapsulates pte_t. It doesn't modify the value > of the pte at all. It's an interface though and so we don't know what is (or can) happen under it. (I also obviously meant "because we are *not* compiled with 5LEVEL") > > Physical address bits are only ever masked away via PTE_PFN_MASK and I > haven't found any place where it is used for a MFN other than those I > touched in this patch. OK. -boris