On 9/30/2016 10:49 AM, Kirti Wankhede wrote:
...
Hi Daniel,
Here you are proposing to add a class named "gpu", which will make all those gpu related attributes mandatory, which libvirt can allow user to better parse/present a particular mdev configuration?
I am just wondering if there is another option that we just make all those attributes that a mdev device can have as optional but still meaningful to libvirt, so libvirt can still parse / recognize them as an class "mdev".
'mdev' isn't a class - mdev is the name of the kernel module. The class refers to the broad capability of the device. class would be things like "gpu", "nic", "fpga" or other such things. The point of the class is to identify which other attributes will be considered mandatory.
Thanks Daniel. This class definition makes sense to me.
However I'm not sure whether we should define such common mandatory attributes of a 'gpu' class now. Intel will go with a 2's power sharing of type definition... actual type name to be finalized, but an example looks like below:
[GVTG-SKL-x2]: available instances (2) [GVTG-SKL-x4]: available instances (4) [GVTG-SKL-x8]: available instances (8) ...
User can create different types of vGPUs simultaneously. A GVTG-SKL-x2 type vGPU will get half of the physical GPU resource, while a GVTG-SKL-x4 type will get a quarter. However it's unclear to me how we want to enumerate those resources into resolution or heads. I feel it'd be more reasonable for us to push initial libvirt mdev support w/o vgpu specific class definition, until we see a clear value of doing so (at that time we then follow Daniel's guideline to define mandatory attributes common to all GPU vendors).
Libvirt won't report arbitrary vendor define attributes. So if we are not going to define a gpu class & associated attributes, then there will be no reporting of the 'heads', 'resolution', 'fb_length' data described above.
yes, that's my point. I think nvidia may put them into the 'description' attribute just for descriptive purpose for now.
Will libvirt report 'description' RO attribute, its output would be string, so that user could be able to see the configuration of that profile?
Daniel, Waiting for your input on this.
We can have 'class' as optional attribute. So Intel don't have to provide 'class' attribute and they don't have to specify mandatory attributes of that class. We would provide 'class' attribute and provide mandatory attributes.
Thanks, Kirti