From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmMUz-0007aB-Vx for qemu-devel@nongnu.org; Tue, 20 Sep 2016 10:58:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bmMUv-0005Ut-9a for qemu-devel@nongnu.org; Tue, 20 Sep 2016 10:58:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmMUv-0005UX-2E for qemu-devel@nongnu.org; Tue, 20 Sep 2016 10:58:13 -0400 Date: Tue, 20 Sep 2016 15:58:08 +0100 From: "Daniel P. Berrange" Message-ID: <20160920145808.GT25490@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> <20160920144152.GS25490@redhat.com> <3426a530-6741-e567-56d7-735bd5c98b54@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3426a530-6741-e567-56d7-735bd5c98b54@redhat.com> Subject: Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kirti Wankhede , Alex Williamson , 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 04:49:09PM +0200, Paolo Bonzini wrote: > > > On 20/09/2016 16:41, Daniel P. Berrange wrote: > > 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. > > Are generic key/value attributes (e.g. a element) acceptable? Only if libvirt has a known list of valid attribute key names upfront. We don't want to just blindly expose arbitary vendor specific keys exposed by the kernel. Libvirt's job is to ensure the XML representation is vendor portable and stable across software versions. If we just blindly expose the strings reported by the host, then the XML will change if the vendor arbitararily renames an attribute in a software update, or if two vendors have the same concept there's no guaranteed name between them. 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 :|