Ping.. Pulling the questions at the top.
>> 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 On 10/3/2016 1:50 PM, Kirti Wankhede wrote: > > > 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 >
