From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yu, Zhang" Subject: Re: [V9 3/3] Differentiate IO/mem resources tracked by ioreq server Date: Thu, 7 Jan 2016 13:38:58 +0800 Message-ID: <568DF9F2.6000304@linux.intel.com> References: <1450145110-2860-1-git-send-email-shuai.ruan@linux.intel.com> <1450145110-2860-4-git-send-email-shuai.ruan@linux.intel.com> <56781EAA02000078000C1F24@prv-mh.provo.novell.com> <5684F687.9000909@linux.intel.com> <568CE56502000078000C3CF1@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: <568CE56502000078000C3CF1@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, Shuai Ruan , andrew.cooper3@citrix.com, stefano.stabellini@eu.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/6/2016 4:59 PM, Jan Beulich wrote: >>>> On 31.12.15 at 10:33, wrote: >> On 12/21/2015 10:45 PM, Jan Beulich wrote: >>>>>> On 15.12.15 at 03:05, wrote: >>>> --- a/xen/include/asm-x86/hvm/domain.h >>>> +++ b/xen/include/asm-x86/hvm/domain.h >>>> @@ -48,8 +48,8 @@ struct hvm_ioreq_vcpu { >>>> bool_t pending; >>>> }; >>>> >>>> -#define NR_IO_RANGE_TYPES (HVMOP_IO_RANGE_PCI + 1) >>>> -#define MAX_NR_IO_RANGES 256 >>>> +#define NR_IO_RANGE_TYPES (HVMOP_IO_RANGE_WP_MEM + 1) >>>> +#define MAX_NR_IO_RANGES 8192 >>> >>> I'm sure I've objected before to this universal bumping of the limit: >>> Even if I were to withdraw my objection to the higher limit on the >>> new kind of tracked resource, I would continue to object to all >>> other resources getting their limits bumped too. >>> >> >> Hah. So how about we keep MAX_NR_IO_RANGES as 256, and use a new value, >> say MAX_NR_WR_MEM_RANGES, set to 8192 in this patch? :) > > That would at least limit the damage to the newly introduced type. > But I suppose you realize it would still be a resource consumption > concern. In order for this to not become a security issue, you > might e.g. stay with the conservative old limit and allow a command > line or even better guest config file override to it (effectively making > the admin state his consent with the higher resource use). Thanks, Jan. I'll try to use the guest config file to set this limit. :) Yu > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >