Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753154AbcL3B1C convert rfc822-to-8bit (ORCPT ); Thu, 29 Dec 2016 20:27:02 -0500 Received: from mga04.intel.com ([192.55.52.120]:63957 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751431AbcL3B1B (ORCPT ); Thu, 29 Dec 2016 20:27:01 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,428,1477983600"; d="scan'208";a="44419928" From: "Li, Liang Z" To: "Valdis.Kletnieks@vt.edu" CC: "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "kirill.shutemov@linux.intel.com" , "dave.hansen@linux.intel.com" , "guangrong.xiao@linux.intel.com" , "pbonzini@redhat.com" , "rkrcmar@redhat.com" Subject: RE: [PATCH RFC 0/4] 5-level EPT Thread-Topic: [PATCH RFC 0/4] 5-level EPT Thread-Index: AQHSYbaExl9WnUhCuEaDs9125fzcHqEe3YUAgADS/9A= Date: Fri, 30 Dec 2016 01:26:57 +0000 Message-ID: References: <1483003563-25847-1-git-send-email-liang.z.li@intel.com> <181888.1483043916@turing-police.cc.vt.edu> In-Reply-To: <181888.1483043916@turing-police.cc.vt.edu> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDhjMmU3YjYtMGZhZS00NDJjLTk2YTYtNDg1ZDVlYTZjMDExIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IktHVXNDa2wrM1VFaHFVZVU3SmFhU3NndzFXUFdBSk5cL0Rnb1FzbndWSHZZPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 989 Lines: 20 > Subject: Re: [PATCH RFC 0/4] 5-level EPT > > On Thu, 29 Dec 2016 17:25:59 +0800, Liang Li said: > > x86-64 is currently limited physical address width to 46 bits, which > > can support 64 TiB of memory. Some vendors require to support more for > > some use case. Intel plans to extend the physical address width to > > 52 bits in some of the future products. > > Can you explain why this patchset mentions 52 bits in some places, and 57 in > others? Is it because there are currently in-process chipsets that will do 52, > but you want to future-proof it by extending it to 57 so future chipsets won't > need more work? Or is there some other reason? The 57-bits I referred in this patch set means the virtual address width which will be supported in the future CPU with 52-bits physical address width. 5 level EPT can support maximum 57-bits physical address width, as long as the future CPU use no more than 57-bits physical address width, no more work is needed. Thanks! Liang