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