From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yu, Zhang" Subject: Re: [PATCH v2 3/3] tools: introduce parameter max_wp_ram_ranges. Date: Wed, 27 Jan 2016 22:56:01 +0800 Message-ID: <56A8DA81.6040109@linux.intel.com> References: <1453432840-5319-1-git-send-email-yu.c.zhang@linux.intel.com> <1453432840-5319-4-git-send-email-yu.c.zhang@linux.intel.com> <56A1EFEE02000078000C9E1E@prv-mh.provo.novell.com> <56A7211C.5040204@linux.intel.com> <56A75FE002000078000CAFBD@prv-mh.provo.novell.com> <56A86B3E.50100@linux.intel.com> <56A8A9A102000078000CB799@prv-mh.provo.novell.com> <56A8D08C.7070804@linux.intel.com> <56A8E31A02000078000CB97A@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: <56A8E31A02000078000CB97A@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 Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, ian.jackson@eu.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 1/27/2016 10:32 PM, Jan Beulich wrote: >>>> On 27.01.16 at 15:13, wrote: >> About the default value: >> You are right. :) For XenGT, MAX_NR_IO_RANGES may only work under >> limited conditions. Having it default to zero means XenGT users must >> manually configure this option. Since we have plans to push other XenGT >> tool stack parameters(including a GVT-g flag), how about we set this >> max_wp_ram_ranges to a default one when GVT-g flag is detected, and >> till then, max_wp_ram_ranges is supposed to be configured explicitly for >> XenGT? > > Sounds reasonable, and in line with what iirc was discussed on > the tool stack side. > Great, and thanks. >> About the truncation issue: >> I do not quite follow. Will this hurt if the value configured does >> not exceed 4G? What about a type cast? > > A typecast would not alter behavior in any way. And of course > a problem only arises if the value was above 4 billion. You either > need to refuse such values while the attempt is made to set it. > or you need to deal with the full range of possible values. Likely > the former is the better (and I wonder whether the upper > bound shouldn't be forced even lower than 4 billion). > Oh, I see. A check with the upper bound sounds better. Using 4G as the upper bound is a little conservative, but I do not have any better criteria right now. :) > Jan > > Thanks Yu