Re: [libvirt] [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration
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 :|