From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfgP0-0004ei-BG for qemu-devel@nongnu.org; Fri, 02 Sep 2016 00:48:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfgOw-0007QQ-0b for qemu-devel@nongnu.org; Fri, 02 Sep 2016 00:48:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfgOv-0007QC-Oo for qemu-devel@nongnu.org; Fri, 02 Sep 2016 00:48:25 -0400 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> From: Michal Privoznik Message-ID: Date: Fri, 2 Sep 2016 06:48:20 +0200 MIME-Version: 1.0 In-Reply-To: <20160901105948.62f750aa@t450s.home> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v7 0/4] Add Mediated device support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: "Song, Jike" , "cjia@nvidia.com" , "kvm@vger.kernel.org" , "libvir-list@redhat.com" , "Tian, Kevin" , "qemu-devel@nongnu.org" , Kirti Wankhede , "kraxel@redhat.com" , Laine Stump , "pbonzini@redhat.com" , "bjsdjshi@linux.vnet.ibm.com" On 01.09.2016 18:59, Alex Williamson wrote: > On Thu, 1 Sep 2016 18:47:06 +0200 > Michal Privoznik wrote: >=20 >> 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 devi= ce >>>> sysfs interface. I'd like to share what I think we agreed on and th= e >>>> "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 take= n >>>> 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, fram= ebuffer, >>>> max_resolution >>>> 11 ,"GRID M60-0B", 16, 2, 45, 512M, 2560= x1600 >>>> 12 ,"GRID M60-0Q", 16, 2, 60, 512M, 2560= x1600 >>>> 13 ,"GRID M60-1B", 8, 2, 45, 1024M, 2560= x1600 >>>> 14 ,"GRID M60-1Q", 8, 2, 60, 1024M, 2560= x1600 >>>> 15 ,"GRID M60-2B", 4, 2, 45, 2048M, 2560= x1600 >>>> 16 ,"GRID M60-2Q", 4, 4, 60, 2048M, 2560= x1600 >>>> 17 ,"GRID M60-4Q", 2, 4, 60, 4096M, 3840= x2160 >>>> 18 ,"GRID M60-8Q", 1, 4, 60, 8192M, 3840= x2160 >>>> >>>> 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 structur= e, >>>> something like: >>>> >>>> =E2=94=9C=E2=94=80=E2=94=80 mdev_destroy >>>> =E2=94=94=E2=94=80=E2=94=80 mdev_supported_types >>>> =E2=94=9C=E2=94=80=E2=94=80 11 >>>> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 create >>>> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 description >>>> =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 max_instances >>>> =E2=94=9C=E2=94=80=E2=94=80 12 >>>> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 create >>>> =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 description >>>> =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 max_instances >>>> =E2=94=94=E2=94=80=E2=94=80 13 >>>> =E2=94=9C=E2=94=80=E2=94=80 create >>>> =E2=94=9C=E2=94=80=E2=94=80 description >>>> =E2=94=94=E2=94=80=E2=94=80 max_instances >>>> >>>> Note that I'm only exposing the minimal attributes here for simplici= ty, >>>> the other attributes would be included in separate files and we woul= d >>>> require vendors to create standard attributes for common device clas= ses. =20 >>> >>> I like this idea. All standard attributes are reflected into this hie= rarchy. >>> In the meantime, can we still allow optional vendor string in create=20 >>> interface? libvirt doesn't need to know the meaning, but allows upper >>> layer to do some vendor specific tweak if necessary. =20 >> >> This is not the best idea IMO. Libvirt is there to shadow differences >> between hypervisors. While doing that, we often hide differences betwe= en >> various types of HW too. Therefore in order to provide good abstractio= n >> 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" fr= om >> example above in domain XML. What I think the better idea is if we let >> users chose resolution and frame buffer size, e.g.: