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: Tue, 2 Feb 2016 18:56:17 +0800 Message-ID: <56B08B51.2030108@linux.intel.com> References: <1454064314-7799-1-git-send-email-yu.c.zhang@linux.intel.com> <1454064314-7799-4-git-send-email-yu.c.zhang@linux.intel.com> <56ABA26C02000078000CC7CD@prv-mh.provo.novell.com> <56ACCAD5.8030503@linux.intel.com> <56AF1CE302000078000CCBBD@prv-mh.provo.novell.com> <20160201120244.GT25660@citrix.com> <56AF5A6402000078000CCEB2@prv-mh.provo.novell.com> <20160201124959.GX25660@citrix.com> <56AF669F02000078000CCF8D@prv-mh.provo.novell.com> <56AF7657.1000200@linux.intel.com> <56AF85A3.6010803@linux.intel.com> <56AF977602000078000CD1BE@prv-mh.provo.novell.com> <56AF89BA.4060105@linux.intel.com> <22191.36960.564997.621538@mariner.uk.xensource.com> <56B093B802000078000CD5FE@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56B093B802000078000CD5FE@prv-mh.provo.novell.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: Jan Beulich , Ian Jackson Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, xen-devel@lists.xen.org, Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, keir@xen.org List-Id: xen-devel@lists.xenproject.org On 2/2/2016 6:32 PM, Jan Beulich wrote: >>>> On 01.02.16 at 18:05, wrote: >> Having said that, if the hypervisor maintainers are happy with a >> situation where this value is configured explicitly, and the >> configurations where a non-default value is required is expected to be >> rare, then I guess we can live with it. > > Well, from the very beginning I have been not very happy with > the introduction of this, and I still consider it half way acceptable > only because of not seeing any good alternative. If we look at > it strictly, it's in violation of the rule we set forth after XSA-77: > No introduction of new code making the system susceptible to > bad (malicious) tool stack behavior, and hence we should reject > it. Yet that would leave XenGT in a state where it would have no > perspective of ever getting merged, which doesn't seem very > desirable either. > > Jan > Thanks, Jan. I understand your concern, and to be honest, I do not think this is an optimal solution. But I also have no better idea in mind. :( Another option may be: instead of opening this parameter to the tool stack, we use a XenGT flag, which set the rangeset limit to a default value. But like I said, this default value may not always work on future XenGT platforms. B.R. Yu