All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kirti Wankhede <kwankhede@nvidia.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Andy Currid <ACurrid@nvidia.com>,
	"Tian, Kevin" <kevin.tian@intel.com>, Neo Jia <cjia@nvidia.com>,
	"libvir-list@redhat.com" <libvir-list@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Song, Jike" <jike.song@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"bjsdjshi@linux.vnet.ibm.com" <bjsdjshi@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration
Date: Tue, 20 Sep 2016 16:14:45 +0100	[thread overview]
Message-ID: <20160920151445.GU25490@redhat.com> (raw)
In-Reply-To: <9e80c4e6-a94f-0fb3-7d57-9ac8ffe53738@redhat.com>

On Tue, Sep 20, 2016 at 05:05:43PM +0200, Paolo Bonzini wrote:
> 
> 
> On 20/09/2016 16:58, 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 <attribute> 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
> 
> Ok, then I guess vendor-specific mdev parameters are out completely.  Or
> could they be added under a separate namespace, like QEMU passthrough?

The QEMU XML namespace that allows passthrough is intended either as a
short term hack to let people experiment with new QEMU features, before
they get explicitly represented in the main XML namespace, or in a few
cases, for things we never want to support officially.  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.

We don't want to knowingly design a system which defacto requires
the app to use the separate namespace most/all of the time.


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 :|

  reply	other threads:[~2016-09-20 15:14 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-19 20:35 [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration Kirti Wankhede
2016-09-19 21:36 ` Alex Williamson
2016-09-19 21:50   ` Paolo Bonzini
2016-09-19 22:25     ` Alex Williamson
2016-09-20 14:35       ` Kirti Wankhede
2016-09-20 14:41         ` Daniel P. Berrange
2016-09-20 14:49           ` Paolo Bonzini
2016-09-20 14:58             ` Daniel P. Berrange
2016-09-20 15:05               ` Paolo Bonzini
2016-09-20 15:14                 ` Daniel P. Berrange [this message]
2016-09-20 16:31                   ` Kirti Wankhede
2016-09-20 16:36                     ` Daniel P. Berrange
2016-09-20 16:42                       ` Kirti Wankhede
2016-09-20 16:44                         ` Daniel P. Berrange
2016-09-20 16:46                     ` Daniel P. Berrange
2016-09-20 17:21                   ` Paolo Bonzini
2016-09-21  8:34                     ` Daniel P. Berrange
2016-09-20 14:52         ` Alex Williamson
2016-09-20  1:25   ` Tian, Kevin
2016-09-20 14:21   ` Kirti Wankhede
2016-09-20 14:43     ` Alex Williamson
2016-09-20 16:23       ` Kirti Wankhede
2016-09-20 16:50         ` Alex Williamson
2016-09-21 18:34           ` Kirti Wankhede
2016-09-21 19:03             ` Alex Williamson
2016-09-22  4:11               ` Kirti Wankhede
2016-09-22 14:19                 ` Alex Williamson
2016-09-22 14:26                   ` [Qemu-devel] [libvirt] " Daniel P. Berrange
2016-09-28 19:22                     ` Neo Jia
2016-09-28 19:45                       ` Tian, Kevin
2016-09-28 19:59                         ` Neo Jia
2016-09-28 20:31                           ` Laine Stump
2016-09-28 20:47                             ` Neo Jia
2016-09-28 22:49                           ` Alex Williamson
2016-09-28 19:55                       ` Alex Williamson
2016-09-28 20:06                         ` Neo Jia
2016-09-28 22:39                           ` Alex Williamson
2016-09-29  8:03                       ` Daniel P. Berrange
2016-09-29  8:12                         ` Neo Jia
2016-09-29 14:22               ` [Qemu-devel] " Kirti Wankhede
2016-09-21  4:10         ` Tian, Kevin
2016-09-21  4:43           ` Alex Williamson
2016-09-22  2:43             ` Tian, Kevin
2016-09-22 19:25         ` Tian, Kevin
2016-09-23 18:34           ` Kirti Wankhede
2016-09-21  3:56     ` Tian, Kevin
2016-09-21  4:36       ` Alex Williamson
2016-09-22  2:33         ` Tian, Kevin
2016-09-22  3:01           ` Alex Williamson
2016-09-22  3:42             ` Tian, Kevin
     [not found]         ` <AADFC41AFE54684AB9EE6CBC0274A5D18DF86F5F@SHSMSX101.ccr.corp.intel.com>
2016-09-22  2:59           ` Tian, Kevin
2016-09-20  1:37 ` Tian, Kevin
2016-09-20  9:47 ` Daniel P. Berrange
2016-09-28 19:48   ` Neo Jia
2016-09-29  8:06     ` Daniel P. Berrange
2016-09-29 14:35       ` Tian, Kevin
2016-09-29 14:38         ` Daniel P. Berrange
2016-09-29 14:42           ` Tian, Kevin
2016-09-30  5:19             ` Kirti Wankhede
2016-10-03  8:20               ` Kirti Wankhede
2016-10-07  5:16                 ` Kirti Wankhede
2016-10-07 19:09                   ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160920151445.GU25490@redhat.com \
    --to=berrange@redhat.com \
    --cc=ACurrid@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=bjsdjshi@linux.vnet.ibm.com \
    --cc=cjia@nvidia.com \
    --cc=jike.song@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kraxel@redhat.com \
    --cc=kwankhede@nvidia.com \
    --cc=libvir-list@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.