From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Privoznik Subject: Re: [Qemu-devel] [PATCH v7 0/4] Add Mediated device support Date: Fri, 2 Sep 2016 06:48:20 +0200 Message-ID: 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" , Kirti Wankhede , "kraxel@redhat.com" , Laine Stump , "pbonzini@redhat.com" , "bjsdjshi@linux.vnet.ibm.com" To: Alex Williamson Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39048 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750823AbcIBEsZ (ORCPT ); Fri, 2 Sep 2016 00:48:25 -0400 In-Reply-To: <20160901105948.62f750aa@t450s.home> Sender: kvm-owner@vger.kernel.org List-ID: 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.: