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 22:01:52 +0800 Message-ID: <56B0B6D0.60303@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56B09D2B02000078000CD696@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 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? Anyway, despite different opinions, I still need to say thank you for your explanation. Upstreaming XenGT features is my task, it is painfully rewarding, to receive suggestions from community maintainers, which helps a newbie like me better understand the virtualization technology. :) Thanks Yu