From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH v2 3/3] tools: introduce parameter max_wp_ram_ranges. Date: Tue, 26 Jan 2016 11:16:14 +0000 Message-ID: <56A7557E.3030701@citrix.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1453432840-5319-4-git-send-email-yu.c.zhang@linux.intel.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: Yu Zhang , xen-devel@lists.xen.org Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, jbeulich@suse.com, wei.liu2@citrix.com List-Id: xen-devel@lists.xenproject.org On 22/01/16 03:20, Yu Zhang wrote: > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -962,6 +962,24 @@ FIFO-based event channel ABI support up to 131,071 event channels. > Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit > x86). > > +=item B > + > +Limit the maximum write-protected ram ranges that can be tracked > +inside one ioreq server rangeset. > + > +Ioreq server uses a group of rangesets to track the I/O or memory > +resources to be emulated. Default limit of ranges that one rangeset > +can allocate is set to a small value, due to the fact that these ranges > +are allocated in xen heap. Yet for the write-protected ram ranges, > +there are circumstances under which the upper limit inside one rangeset > +should exceed the default one. E.g. in XenGT, when tracking the per- > +process graphic translation tables on intel broadwell platforms, the > +number of page tables concerned will be several thousand(normally > +in this case, 8192 could be a big enough value). Not configuring this > +item, or setting its value to 0 will result in the upper limit set > +to its default one. Users who set his item explicitly are supposed > +to know the specific scenarios that necessitate this configuration. This help text isn't very helpful. How is a user supposed to "know the specific scenarios" that need this option? Why doesn't the toolstack (or qemu) automatically set this value based on whether GVT-g/GVT-d is being used? Then there is no need to even present this option to the user. David