From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfVLH-0006Wt-U8 for qemu-devel@nongnu.org; Thu, 01 Sep 2016 12:59:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfVLD-0003S2-Qp for qemu-devel@nongnu.org; Thu, 01 Sep 2016 12:59:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49398) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfVLD-0003Ro-Ih for qemu-devel@nongnu.org; Thu, 01 Sep 2016 12:59:51 -0400 Date: Thu, 1 Sep 2016 10:59:48 -0600 From: Alex Williamson Message-ID: <20160901105948.62f750aa@t450s.home> In-Reply-To: <78fedd65-6d62-e849-ff3b-d5105b2da816@redhat.com> References: <1472097235-6332-1-git-send-email-kwankhede@nvidia.com> <20160830101638.49df467d@t450s.home> <78fedd65-6d62-e849-ff3b-d5105b2da816@redhat.com> MIME-Version: 1.0 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: Michal Privoznik Cc: "Tian, Kevin" , Kirti Wankhede , "Song, Jike" , "cjia@nvidia.com" , "kvm@vger.kernel.org" , "libvir-list@redhat.com" , "qemu-devel@nongnu.org" , "kraxel@redhat.com" , Laine Stump , "pbonzini@redhat.com" , "bjsdjshi@linux.vnet.ibm.com" 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, frameb= uffer, > >> max_resolution > >> 11 ,"GRID M60-0B", 16, 2, 45, 512M, 2560x1= 600 > >> 12 ,"GRID M60-0Q", 16, 2, 60, 512M, 2560x1= 600 > >> 13 ,"GRID M60-1B", 8, 2, 45, 1024M, 2560x1= 600 > >> 14 ,"GRID M60-1Q", 8, 2, 60, 1024M, 2560x1= 600 > >> 15 ,"GRID M60-2B", 4, 2, 45, 2048M, 2560x1= 600 > >> 16 ,"GRID M60-2Q", 4, 4, 60, 2048M, 2560x1= 600 > >> 17 ,"GRID M60-4Q", 2, 4, 60, 4096M, 3840x2= 160 > >> 18 ,"GRID M60-8Q", 1, 4, 60, 8192M, 3840x2= 160 > >> > >> 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: > >> > >> =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 simplicity, > >> the other attributes would be included in separate files and we would > >> require vendors to create standard attributes for common device classe= s. =20 > >=20 > > I like this idea. All standard attributes are reflected into this hiera= rchy. > > 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 >=20 > 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.: