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 21:56:45 +0800 Message-ID: <56B0B59D.9020800@linux.intel.com> References: <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> <56B062FE.4030907@linux.intel.com> <20160202115157.GZ25660@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160202115157.GZ25660@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: Wei Liu Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, Ian Jackson , xen-devel@lists.xen.org, Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, Jan Beulich List-Id: xen-devel@lists.xenproject.org On 2/2/2016 7:51 PM, Wei Liu wrote: > On Tue, Feb 02, 2016 at 04:04:14PM +0800, Yu, Zhang wrote: >> Thanks for your reply, Ian. >> >> On 2/2/2016 1:05 AM, Ian Jackson wrote: >>> Yu, Zhang writes ("Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges."): >>>> On 2/2/2016 12:35 AM, Jan Beulich wrote: >>>>> On 01.02.16 at 17:19, wrote: >>>>>> So, we need also validate this param in hvm_allow_set_param, >>>>>> current although hvm_allow_set_param has not performed any >>>>>> validation other parameters. We need to do this for the new >>>>>> ones. Is this understanding correct? >>>>> >>>>> Yes. >>>>> >>>>>> Another question is: as to the tool stack side, do you think >>>>>> an error message would suffice? Shouldn't xl be terminated? >>>>> >>>>> I have no idea what consistent behavior in such a case would >>>>> be - I'll defer input on this to the tool stack maintainers. >>>> >>>> Thank you. >>>> Wei, which one do you prefer? >>> >>> I think that arrangements should be made for the hypercall failure to >>> be properly reported to the caller, and properly logged. >>> >>> I don't think it is desirable to duplicate the sanity check in >>> xl/libxl/libxc. That would simply result in there being two limits to >>> update. >>> >> >> Sorry, I do not follow. What does "being two limits to update" mean? >> > > I can't speak for Ian, but my understanding is that if the code logic is > duplicated in several places, you need to update all of them whenever > you change the logic. But, he has expressed if this is blocker for this > series, so I will let him clarify. Thank you, Wei. This explanation helps. :) B.R. Yu