On 10/12/2016 9:29 PM, Alex Williamson wrote: > On Wed, 12 Oct 2016 20:43:48 +0530 > Kirti Wankhede <kwankhede@xxxxxxxxxx> wrote: > >> On 10/12/2016 7:22 AM, Tian, Kevin wrote: >>>> From: Kirti Wankhede [mailto:kwankhede@xxxxxxxxxx] >>>> Sent: Wednesday, October 12, 2016 4:45 AM >>>>>> +* mdev_supported_types: >>>>>> + List of current supported mediated device types and its details are added >>>>>> +in this directory in following format: >>>>>> + >>>>>> +|- <parent phy device> >>>>>> +|--- Vendor-specific-attributes [optional] >>>>>> +|--- mdev_supported_types >>>>>> +| |--- <type id> >>>>>> +| | |--- create >>>>>> +| | |--- name >>>>>> +| | |--- available_instances >>>>>> +| | |--- description /class >>>>>> +| | |--- [devices] >>>>>> +| |--- <type id> >>>>>> +| | |--- create >>>>>> +| | |--- name >>>>>> +| | |--- available_instances >>>>>> +| | |--- description /class >>>>>> +| | |--- [devices] >>>>>> +| |--- <type id> >>>>>> +| |--- create >>>>>> +| |--- name >>>>>> +| |--- available_instances >>>>>> +| |--- description /class >>>>>> +| |--- [devices] >>>>>> + >>>>>> +[TBD : description or class is yet to be decided. This will change.] >>>>> >>>>> I thought that in previous discussions we had agreed to drop >>>>> the <type id> concept and use the name as the unique identifier. >>>>> When reporting these types in libvirt we won't want to report >>>>> the type id values - we'll want the name strings to be unique. >>>>> >>>> >>>> The 'name' might not be unique but type_id will be. For example that Neo >>>> pointed out in earlier discussion, virtual devices can come from two >>>> different physical devices, end user would be presented with what they >>>> had selected but there will be internal implementation differences. In >>>> that case 'type_id' will be unique. >>>> >>> >>> Hi, Kirti, my understanding is that Neo agreed to use an unique type >>> string (if you still called it <type id>), and then no need of additional >>> 'name' field which can be put inside 'description' field. See below quote: >>> >> >> We had internal discussions about this within NVIDIA and found that >> 'name' might not be unique where as 'type_id' would be unique. I'm >> refering to Neo's mail after that, where Neo do pointed that out. >> >> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg07714.html > > Everyone not privy to those internal discussions, including me, seems to > think we dropped type_id and that if a vendor does not have a stable > name, they can compose some sort of stable type description based on the > name+id, or even vendor+id, ex. NVIDIA-11. So please share why we > haven't managed to kill off type_id yet. No matter what internal > representation each vendor driver has of "type_id" it seems possible > for it to come up with stable string to define a given configuration. The 'type_id' is unique and the 'name' are not, the name is just a virtual device name/ human readable name. Because at this moment Intel can't define a proper GPU class, we have to add a 'description' field there as well to represent the features of this virtual device, once we have all agreed with the GPU class and its mandatory attributes, the 'description' field can be removed. Here is an example, type_id/type_name = NVIDIA_11, name=M60-M0Q, description=2560x1600, 2 displays, 512MB" Neo's previous comment only applies to the situation where we will have the GPU class or optional attributes defined and recognized by libvirt, since that is not going to happen any time soon, we will have to have the new 'description' field, and we don't want to have it mixed up with 'name' field. We can definitely have something like name+id as Alex recommended to remove the 'name' field, but it will just require libvirt to have more logic to parse that string. Thanks, Kirti -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
