From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges. Date: Tue, 02 Feb 2016 03:32:07 -0700 Message-ID: <56B093B802000078000CD5FE@prv-mh.provo.novell.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <22191.36960.564997.621538@mariner.uk.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: 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, Zhang Yu , zhiyuan.lv@intel.com, keir@xen.org List-Id: xen-devel@lists.xenproject.org >>> 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