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 23:00:21 +0800 Message-ID: <56B0C485.8070206@linux.intel.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> <56B093B802000078000CD5FE@prv-mh.provo.novell.com> <56B08B51.2030108@linux.intel.com> <56B09D2B02000078000CD696@prv-mh.provo.novell.com> <56B0B6D0.60303@linux.intel.com> <56B0CE8102000078000CD8D4@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: <56B0CE8102000078000CD8D4@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 , xen-devel@lists.xen.org, Paul.Durrant@citrix.com, zhiyuan.lv@intel.com, keir@xen.org List-Id: xen-devel@lists.xenproject.org On 2/2/2016 10:42 PM, Jan Beulich wrote: >>>> On 02.02.16 at 15:01, wrote: >> On 2/2/2016 7:12 PM, Jan Beulich wrote: >>>>>> On 02.02.16 at 11:56, wrote: >>>> I understand your concern, and to be honest, I do not think >>>> this is an optimal solution. But I also have no better idea >>>> in mind. :( >>>> Another option may be: instead of opening this parameter to >>>> the tool stack, we use a XenGT flag, which set the rangeset >>>> limit to a default value. But like I said, this default value >>>> may not always work on future XenGT platforms. >>> >>> Assuming that you think of something set e.g. by hypervisor >>> command line option: How would that work? I.e. how would >>> that limit the resource use for all VMs not using XenGT? Or if >>> you mean a flag settable in the domain config - how would you >>> avoid a malicious admin to set this flag for all the VMs created >>> in the controlled partition of the system? >> >> Well, I am not satisfied with this new parameter, because: >> 1> exposing an option like max_wp_ram_ranges to the user seems too >> detailed; >> 2> but if not, using a XenGT flag means it would be hard for hypervisor >> to find a default value which can work in all situations theoretically, >> although in practice, 8K is already a big enough one. >> >> However, as to the security concern you raised, I can not fully >> understand. :) E.g. I believe a malicious admin can also breach the >> system even without this patch. This argument may not be convincing to >> you, but as to this specific case, even if an admin set XenGT flag to >> all VMs, what harm will this action do? It only means the ioreq server >> can at most allocate 8K ranges, will that consume all the Xen heaps, >> especially for 64 bit Xen? > > First of all so far you meant to set a limit of 4G, which - taking a > handful of domains - if fully used would take even a mid-size > host out of memory. And then you have to consider bad effects > resulting from Xen itself not normally having a lot of memory left > (especially when "dom0_mem=" is not forcing most of the memory > to be in Xen's hands), which may mean that one domain > exhausting Xen's memory can affect another domain if Xen can't > allocate memory it needs to support that other domain, in the > worst case leading to a domain crash. And this all is still leaving > aside Xen's own health... > Thanks, Jan. The limit of 4G is to avoid the data missing from uint64 to uint32 assignment. And I can accept the 8K limit for XenGT in practice. After all, it is vGPU page tables we are trying to trap and emulate, not normal page frames. And I guess the reason that one domain exhausting Xen's memory can affect another domain is because rangeset uses Xen heap, instead of the per-domain memory. So what about we use a 8K limit by now for XenGT, and in the future, if a per-domain memory allocation solution for rangeset is ready, we do need to limit the rangeset size. Does this sounds more acceptable? B.R. Yu