On 9/20/2016 8:44 PM, Daniel P. Berrange wrote: > 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 >>
In key/value attributes (taking example from proposed xml file) <attribute name='resolution'>2560x1600</attribute> 'Key' (i.e. 'resolution') should be known upfront, not the value, right? Kirti >> 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 >
