From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6741EC4360D for ; Thu, 26 Sep 2019 08:13:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 48812222BE for ; Thu, 26 Sep 2019 08:13:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729440AbfIZIMx (ORCPT ); Thu, 26 Sep 2019 04:12:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60708 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726252AbfIZIMx (ORCPT ); Thu, 26 Sep 2019 04:12:53 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EDECB10DCC92; Thu, 26 Sep 2019 08:12:51 +0000 (UTC) Received: from [10.72.12.101] (ovpn-12-101.pek2.redhat.com [10.72.12.101]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5601D60C80; Thu, 26 Sep 2019 08:12:23 +0000 (UTC) Subject: Re: [PATCH V2 6/8] mdev: introduce virtio device and its device ops To: "Tian, Kevin" , "kvm@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "intel-gfx@lists.freedesktop.org" , "intel-gvt-dev@lists.freedesktop.org" , "kwankhede@nvidia.com" , "alex.williamson@redhat.com" , "mst@redhat.com" , "Bie, Tiwei" Cc: "christophe.de.dinechin@gmail.com" , "sebott@linux.ibm.com" , "airlied@linux.ie" , "joonas.lahtinen@linux.intel.com" , "heiko.carstens@de.ibm.com" , "virtualization@lists.linux-foundation.org" , "rob.miller@broadcom.com" , "lulu@redhat.com" , "eperezma@redhat.com" , "pasic@linux.ibm.com" , "borntraeger@de.ibm.com" , "haotian.wang@sifive.com" , "Wang, Zhi A" , "farman@linux.ibm.com" , "idos@mellanox.com" , "gor@linux.ibm.com" , "Liang, Cunming" , "zhenyuw@linux.intel.com" , "Vivi, Rodrigo" , "Wang, Xiao W" , "freude@linux.ibm.com" , "jani.nikula@linux.intel.com" , "parav@mellanox.com" , "Wang, Zhihong" , "akrowiak@linux.ibm.com" , "netdev@vger.kernel.org" , "cohuck@redhat.com" , "oberpar@linux.ibm.com" , "maxime.coquelin@redhat.com" , "daniel@ffwll.ch" , "Zhu, Lingshan" References: <20190924135332.14160-1-jasowang@redhat.com> <20190924135332.14160-7-jasowang@redhat.com> <2210d23d-38e4-e654-e53d-7867348de86a@redhat.com> From: Jason Wang Message-ID: <6ba16bf8-8e8a-343a-335d-ab77d7cda195@redhat.com> Date: Thu, 26 Sep 2019 16:12:07 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.64]); Thu, 26 Sep 2019 08:12:52 +0000 (UTC) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 2019/9/26 上午8:48, Tian, Kevin wrote: >>>> +}; >>> I'm not sure how stable above ops are. >> It's the kernel internal API, so there's no strict requirement for this. >> We will export a version value for userspace for compatibility. >> >> >>> Does it make sense if defining >>> just two callbacks here, e.g. vq_ctrl and device_ctrl, and then let the >>> vendor driver to handle specific ops in each category (similar to how >>> ioctl works)? >> My understanding is that it introduce another indirection, you still >> need to differ from different command, and it's less flexible than >> direct callback. >> >> What's the value of doing this? >> > I just thought doing so may provide better compatibility to the > parent driver. Even when new op is introduced, a parent driver > that was developed against the old set can still be loaded in the > new kernel. It just returns error when unrecognized ops are > routed through vq_ctrl and device_ctrl, if the userspace doesn't > favor the exposed version value. But if above ops set is pretty > stable, then this comment can be ignored. This is really good point, we should keep it stable as a real transport. And when there's major changes, we should advertise through version then we can provide a new set of functions. Thanks > > Thanks > Kevin