From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yu, Zhang" Subject: Re: [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges. Date: Thu, 4 Feb 2016 16:51:08 +0800 Message-ID: <56B310FC.1000503@linux.intel.com> References: <1454064314-7799-1-git-send-email-yu.c.zhang@linux.intel.com> <56B0B6D0.60303@linux.intel.com> <56B0CE8102000078000CD8D4@prv-mh.provo.novell.com> <56B0C485.8070206@linux.intel.com> <56B0D7A202000078000CD989@prv-mh.provo.novell.com> <56B1A7C9.2010708@linux.intel.com> <56B1C93002000078000CDD4B@prv-mh.provo.novell.com> <6b6d0558d3c24f9483ad41d88ced9837@AMSPEX02CL03.citrite.net> <56B2023E02000078000CE01A@prv-mh.provo.novell.com> <7316ea5cb41543d69d7727721368e3c8@AMSPEX02CL03.citrite.net> <56B207EA02000078000CE0A8@prv-mh.provo.novell.com> <9467b97e15bc4cb1b8d6c948ad4fc926@AMSPEX02CL03.citrite.net> <56B20BFA02000078000CE0E7@prv-mh.provo.novell.com> <621ce95774ac4742b96ed9d504c08670@AMSPEX02CL03.citrite.net> <22194.4639.132613.604758@mariner.uk.xensource.com> <56B24947.4070700@citrix.com> <56B2510A.8040702@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56B2510A.8040702@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Andrew Cooper , George Dunlap , Ian Jackson Cc: Kevin Tian , Wei Liu , Ian Campbell , "xen-devel@lists.xen.org" , Paul Durrant , Stefano Stabellini , "zhiyuan.lv@intel.com" , Jan Beulich , "Keir (Xen.org)" List-Id: xen-devel@lists.xenproject.org On 2/4/2016 3:12 AM, George Dunlap wrote: > On 03/02/16 18:39, Andrew Cooper wrote: >> On 03/02/16 18:21, George Dunlap wrote: >>> 2. It's not technically difficult to extend the number of servers >>> supported to something sensible, like 4 (using 4 different write_dm >>> p2m types) >> >> While technically true, spare bits in the pagetable entries are at a >> premium, and steadily decreasing as Intel are introducing new features. >> >> We have 16 current p2m types, and a finite upper bound of 6 bits of p2m >> type space, already with a push to reduce this number. >> >> While introducing 1 new p2m type for this purpose might be an acceptable >> tradeoff, a using a p2m type per ioreq server is not IMO. > > It is true that we don't have a ton of elbow room to grow at the moment. > > But we actually already have a single p2m type -- mmio_write_dm -- that > as far as I know is only being used by XenGT. We don't actually need to > add any new p2m types for my initial proposal. > > Going forward, we probably will, at some point, need to implement a > parallel "p2t" structure to keep track of types -- and probably will > whether end up implementing 4 separate write_dm types or not (for the > reasons you describe). > Thank you, George. Could you please elaborate more about the idea of "p2t"? Yu