Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

From: Kirti Wankhede <kwankhede@nvidia.com>
To: "Daniel P. Berrange" <berrange@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: 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 22:01:18 +0530	[thread overview]
Message-ID: <ce542157-843a-894d-8724-77c6b56806ed@nvidia.com> (raw)
In-Reply-To: <20160920151445.GU25490@redhat.com>

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
> 