From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Durrant Subject: Re: [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges. Date: Thu, 4 Feb 2016 14:25:16 +0000 Message-ID: <3eaca9ee3fb34adbac7cce14301953c7@AMSPEX02CL03.citrite.net> References: <1454064314-7799-1-git-send-email-yu.c.zhang@linux.intel.com> <56B0CE8102000078000CD8D4@prv-mh.provo.novell.com> <56B0C485.8070206@linux.intel.com> <56B0D7A202000078000CD989@prv-mh.provo.novell.com> <56B1A7C9.2010708@linux.intel.com> <56B1C93002000078000CDD4B@prv-mh.provo.novell.com> <6b6d0558d3c24f9483ad41d88ced9837@AMSPEX02CL03.citrite.net> <56B2023E02000078000CE01A@prv-mh.provo.novell.com> <7316ea5cb41543d69d7727721368e3c8@AMSPEX02CL03.citrite.net> <56B207EA02000078000CE0A8@prv-mh.provo.novell.com> <9467b97e15bc4cb1b8d6c948ad4fc926@AMSPEX02CL03.citrite.net> <56B20BFA02000078000CE0E7@prv-mh.provo.novell.com> <621ce95774ac4742b96ed9d504c08670@AMSPEX02CL03.citrite.net> <22194.4639.132613.604758@mariner.uk.xensource.com> <56B310D7.7010506@linux.intel.com> <44e528cd11744242961d46c6f87d2bb9@AMSPEX02CL03.citrite.net> <56B31C1C.3000907@linux.intel.com> <56B3373B02000078000CE86C@prv-mh.provo.novell.com> <22195.21299.624759.118961@mariner.uk.xensource.com> <347fa8fe5fdc4ba8adb6bc4502926838@AMSPEX02CL03.citrite.net> <56B36A6302000078000CE9E8@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56B36A6302000078000CE9E8@prv-mh.provo.novell.com> Content-Language: en-US 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 , Wei Liu , Ian Campbell , Andrew Cooper , Zhang Yu , George Dunlap , "xen-devel@lists.xen.org" , Stefano Stabellini , "zhiyuan.lv@intel.com" , Ian Jackson , "Keir (Xen.org)" List-Id: xen-devel@lists.xenproject.org > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: 04 February 2016 14:13 > To: Paul Durrant > Cc: Andrew Cooper; George Dunlap; Ian Campbell; Ian Jackson; Stefano > Stabellini; Wei Liu; Kevin Tian; zhiyuan.lv@intel.com; Zhang Yu; xen- > devel@lists.xen.org; Keir (Xen.org) > Subject: RE: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter > max_wp_ram_ranges. > > >>> On 04.02.16 at 14:47, wrote: > >> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > >> Sent: 04 February 2016 13:34 > >> * Is it possible for libxl to somehow tell from the rest of the > >> configuration that this larger limit should be applied ? > >> > >> AFAICT there is nothing in libxl directly involving vgpu. How can > >> libxl be used to create a guest with vgpu enabled ? I had thought > >> that this was done merely with the existing PCI passthrough > >> configuration, but it now seems that somehow a second device model > >> would have to be started. libxl doesn't have code to do that. > >> > > > > AIUI if the setting of the increased limit is tied to provisioning a gvt-g > > instance for a VM then I don't there needs to be extra information in the > VM > > config. These seems like the most sensible thing to do. > > I don't understand this: For one, it's still unclear to me on what basis > it would be known that a given VM is a "gvt-g instance". And even if > that's indeed derivable from something, the uncertainty about a > workable upper bound on the number of WP ranges would still seem > to demand the value to be specifiable separately... There are patches in the XenGT xen repo which add extra parameters into the VM config to allow libxl to provision a gvt-g instance (of which there are a finite number per GPU) for a VM. The increased limit could be applied when doing so and it may be feasible to determine (maybe from the version of the GPU h/w) what a reasonable limit is. Paul > > >> I now understand that these mmio ranges are created by the device > >> model. Of course the device model needs to be able to create mmio > >> ranges for the guest. And since they consume hypervisor resources, > >> the number of these must be limited (device models not necessarily > >> being trusted). > > > > ...but I think there is still an open question as to whether the toolstack > > is allowed to set that limit for a VM or not. IMO the toolstack should be > > allowed to set that limit when creating a domain. > > ... as you indicate here. > > Jan