From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55999) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmMFG-0002Pv-Ol for qemu-devel@nongnu.org; Tue, 20 Sep 2016 10:42:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bmMFC-0001qW-3k for qemu-devel@nongnu.org; Tue, 20 Sep 2016 10:42:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmMFB-0001q9-QQ for qemu-devel@nongnu.org; Tue, 20 Sep 2016 10:41:58 -0400 Date: Tue, 20 Sep 2016 15:41:52 +0100 From: "Daniel P. Berrange" Message-ID: <20160920144152.GS25490@redhat.com> Reply-To: "Daniel P. Berrange" References: <00d96f24-5df0-d16b-d4e1-838333989dee@nvidia.com> <20160919153600.70599974@t450s.home> <8e7e7357-cad4-f9ca-4104-97cadd347a13@redhat.com> <20160919162521.3569caa2@t450s.home> <32b91537-0d83-a312-db19-7341650c3d4a@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <32b91537-0d83-a312-db19-7341650c3d4a@nvidia.com> Subject: Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kirti Wankhede Cc: Alex Williamson , Paolo Bonzini , Andy Currid , "Tian, Kevin" , Neo Jia , "libvir-list@redhat.com" , qemu-devel , "Song, Jike" , Gerd Hoffmann , "bjsdjshi@linux.vnet.ibm.com" On Tue, Sep 20, 2016 at 08:05:01PM +0530, Kirti Wankhede wrote: > > > On 9/20/2016 3:55 AM, Alex Williamson wrote: > > On Mon, 19 Sep 2016 23:50:56 +0200 > > Paolo Bonzini wrote: > > > >> On 19/09/2016 23:36, Alex Williamson wrote: > >>> On Tue, 20 Sep 2016 02:05:52 +0530 > >>> Kirti Wankhede wrote: > >>>> 'fb_length': > >>>> Read-only file. Mandatory. > >>>> Returns {K,M,G}, size of framebuffer. > >>> > >>> This can't be mandatory, it's only relevant to vGPU devices, vGPUs are > >>> just one user of mediated devices. [...] > >>> > >>>> 'params' > >>>> Write-Only file. Optional. > >>>> String input. Libvirt would pass the string given in XML file to > >>>> this file and then create mdev device. Set empty string to clear params. > >>>> For example, set parameter 'frame_rate_limiter=0' to disable frame rate > >>>> limiter for performance benchmarking, then create device of type 11. The > >>>> device created would have that parameter set by vendor driver. > >>> > >>> Might as well just call it "magic", there's absolutely no ability to > >>> introspect what parameters are allowed or even valid here. Can all > >>> parameters be changed dynamically? Do parameter changes apply to > >>> existing devices or only future devices? This is a poorly specified > >>> interface. I'd prefer this be done via module options on the vendor > >>> driver. > >> > >> Or additional files in the mdev's sysfs directory? > > > > Sure, the vendor driver could certainly support that, it'd be vendor > > specific of course. > > > > Right, it would be vendor specific. But if this is not set through mdev > device XML, user have to create mdev device with XML first and then > manually set such parameter. Also these parameters would not retain if > mdev device is destroyed and created again. That's why if libvirt sets > these parameters by reading it from XML file, it would be simple for user. > > If we move 'params' file to mdev device, could libvirt do the following > to create mdev device: > > * Read /sys/../0000\:86\:00.0/11/max_instances. If it is greater than 0, > then only proceed else fail. > > * Autogenerate UUID > * Create device: > > echo "$UUID" > /sys/../0000\:86\:00.0/11/create > > * Set extra params if 'params' field exist in device XML and 'params' > file exist mdev device directory: > > echo "frame_rate_limiter=0" > /sys/bus/mdev/devices/$UUID/params As I've said in my earlier reply - libvirt will *NOT* support passing arbitrary vendor specific parameters as a blob via the XML. Everything that appears in the XML must be *fully* specified and explicitly represented in the XML as a distinct attribute or element. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|