From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmczV-00082M-N6 for qemu-devel@nongnu.org; Wed, 21 Sep 2016 04:34:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bmczS-0001Bc-Fo for qemu-devel@nongnu.org; Wed, 21 Sep 2016 04:34:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmczS-0001BO-A8 for qemu-devel@nongnu.org; Wed, 21 Sep 2016 04:34:50 -0400 Date: Wed, 21 Sep 2016 09:34:44 +0100 From: "Daniel P. Berrange" Message-ID: <20160921083444.GA15535@redhat.com> Reply-To: "Daniel P. Berrange" References: <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> <20160920145808.GT25490@redhat.com> <9e80c4e6-a94f-0fb3-7d57-9ac8ffe53738@redhat.com> <20160920151445.GU25490@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 07:21:07PM +0200, Paolo Bonzini wrote: > > > On 20/09/2016 17:14, Daniel P. Berrange wrote: > > Any VM which > > uses the separate namespace is tainted, which means if theres a bug > > report we'll require the reported to remove whatever config caused > > the tainting and then reproduce the problem. > > > > If the vendor specific mdev parameters are things that apps will often > > need to be able to set, then allowing it via a separate namespace is > > just providing a backdoor that everyone needs to use, defeating the > > point of using a separate namespace. > > No, they don't need to be often set, and tainting the domain is a good idea. Basically think of the XML namespace support as "a mechanism for accessing underlying platform features before they are exposed in the main XML, that happens to use the vendor specific data format" *not* as "a mechanism for exposing vendor specific functionality" 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 :|