From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kirti Wankhede Subject: Re: [Qemu-devel] [PATCH v7 0/4] Add Mediated device support Date: Fri, 2 Sep 2016 10:51:45 +0530 Message-ID: <98bbdbbf-c388-9120-3306-64f0cfb820a7@nvidia.com> References: <1472097235-6332-1-git-send-email-kwankhede@nvidia.com> <20160830101638.49df467d@t450s.home> <78fedd65-6d62-e849-ff3b-d5105b2da816@redhat.com> <20160901105948.62f750aa@t450s.home> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Cc: "Song, Jike" , "cjia@nvidia.com" , "kvm@vger.kernel.org" , "libvir-list@redhat.com" , "Tian, Kevin" , "qemu-devel@nongnu.org" , "kraxel@redhat.com" , Laine Stump , "pbonzini@redhat.com" , "bjsdjshi@linux.vnet.ibm.com" To: Michal Privoznik , Alex Williamson Return-path: Received: from hqemgate16.nvidia.com ([216.228.121.65]:6053 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751282AbcIBFWz (ORCPT ); Fri, 2 Sep 2016 01:22:55 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 9/2/2016 10:18 AM, Michal Privoznik wrote: > On 01.09.2016 18:59, Alex Williamson wrote: >> On Thu, 1 Sep 2016 18:47:06 +0200 >> Michal Privoznik wrote: >> >>> On 31.08.2016 08:12, Tian, Kevin wrote: >>>>> From: Alex Williamson [mailto:alex.williamson@redhat.com] >>>>> Sent: Wednesday, August 31, 2016 12:17 AM >>>>> >>>>> Hi folks, >>>>> >>>>> At KVM Forum we had a BoF session primarily around the mediated device >>>>> sysfs interface. I'd like to share what I think we agreed on and the >>>>> "problem areas" that still need some work so we can get the thoughts >>>>> and ideas from those who weren't able to attend. >>>>> >>>>> DanPB expressed some concern about the mdev_supported_types sysfs >>>>> interface, which exposes a flat csv file with fields like "type", >>>>> "number of instance", "vendor string", and then a bunch of type >>>>> specific fields like "framebuffer size", "resolution", "frame rate >>>>> limit", etc. This is not entirely machine parsing friendly and sort of >>>>> abuses the sysfs concept of one value per file. Example output taken >>>>> from Neo's libvirt RFC: >>>>> >>>>> cat /sys/bus/pci/devices/0000:86:00.0/mdev_supported_types >>>>> # vgpu_type_id, vgpu_type, max_instance, num_heads, frl_config, framebuffer, >>>>> max_resolution >>>>> 11 ,"GRID M60-0B", 16, 2, 45, 512M, 2560x1600 >>>>> 12 ,"GRID M60-0Q", 16, 2, 60, 512M, 2560x1600 >>>>> 13 ,"GRID M60-1B", 8, 2, 45, 1024M, 2560x1600 >>>>> 14 ,"GRID M60-1Q", 8, 2, 60, 1024M, 2560x1600 >>>>> 15 ,"GRID M60-2B", 4, 2, 45, 2048M, 2560x1600 >>>>> 16 ,"GRID M60-2Q", 4, 4, 60, 2048M, 2560x1600 >>>>> 17 ,"GRID M60-4Q", 2, 4, 60, 4096M, 3840x2160 >>>>> 18 ,"GRID M60-8Q", 1, 4, 60, 8192M, 3840x2160 >>>>> >>>>> The create/destroy then looks like this: >>>>> >>>>> echo "$mdev_UUID:vendor_specific_argument_list" > >>>>> /sys/bus/pci/devices/.../mdev_create >>>>> >>>>> echo "$mdev_UUID:vendor_specific_argument_list" > >>>>> /sys/bus/pci/devices/.../mdev_destroy >>>>> >>>>> "vendor_specific_argument_list" is nebulous. >>>>> >>>>> So the idea to fix this is to explode this into a directory structure, >>>>> something like: >>>>> >>>>> ├── mdev_destroy >>>>> └── mdev_supported_types >>>>> ├── 11 >>>>> │ ├── create >>>>> │ ├── description >>>>> │ └── max_instances >>>>> ├── 12 >>>>> │ ├── create >>>>> │ ├── description >>>>> │ └── max_instances >>>>> └── 13 >>>>> ├── create >>>>> ├── description >>>>> └── max_instances >>>>> >>>>> Note that I'm only exposing the minimal attributes here for simplicity, >>>>> the other attributes would be included in separate files and we would >>>>> require vendors to create standard attributes for common device classes. >>>> >>>> I like this idea. All standard attributes are reflected into this hierarchy. >>>> In the meantime, can we still allow optional vendor string in create >>>> interface? libvirt doesn't need to know the meaning, but allows upper >>>> layer to do some vendor specific tweak if necessary. >>> >>> This is not the best idea IMO. Libvirt is there to shadow differences >>> between hypervisors. While doing that, we often hide differences between >>> various types of HW too. Therefore in order to provide good abstraction >>> we should make vendor specific string as small as possible (ideally an >>> empty string). I mean I see it as bad idea to expose "vgpu_type_id" from >>> example above in domain XML. What I think the better idea is if we let >>> users chose resolution and frame buffer size, e.g.: