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.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 22082C432C0 for ; Mon, 25 Nov 2019 13:00:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EB8682082F for ; Mon, 25 Nov 2019 12:59:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="CphYnXv+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725823AbfKYM77 (ORCPT ); Mon, 25 Nov 2019 07:59:59 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:46534 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727300AbfKYM77 (ORCPT ); Mon, 25 Nov 2019 07:59:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574686797; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Cdk+dECH005B5t1f94C8RSsQ86cze75hgG33FXnZQFU=; b=CphYnXv+bpPfuNFEhKZm+3AXAaisJZjz58mT91A44sgGbIBW+2mLo+jennpmAIVGdDEDIk 1ESZAQYD4ClF+VupllcWTZcmFtP3tl6yV8PeXjJogtMzm8yhgfkWL27mBvqr3j6G0Cfm/H F7EtDLrMX5AIMXg7YA4T2SYfTS7WXf4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-50-EC6sypjEMtSlqN8YDpjaPg-1; Mon, 25 Nov 2019 07:59:56 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5D18664A80; Mon, 25 Nov 2019 12:59:54 +0000 (UTC) Received: from [10.72.12.44] (ovpn-12-44.pek2.redhat.com [10.72.12.44]) by smtp.corp.redhat.com (Postfix) with ESMTP id 01F665C1D4; Mon, 25 Nov 2019 12:59:43 +0000 (UTC) Subject: Re: [net-next v2 1/1] virtual-bus: Implementation of Virtual Bus To: Jason Gunthorpe , Tiwei Bie Cc: Alex Williamson , "Michael S. Tsirkin" , Parav Pandit , Jeff Kirsher , davem@davemloft.net, gregkh@linuxfoundation.org, Dave Ertman , netdev@vger.kernel.org, linux-rdma@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com, Kiran Patil References: <20191120181108.GJ22515@ziepe.ca> <20191120150732.2fffa141@x1.home> <20191121030357.GB16914@ziepe.ca> <5dcef4ab-feb5-d116-b2a9-50608784a054@redhat.com> <20191121141732.GB7448@ziepe.ca> <721e49c2-a2e1-853f-298b-9601c32fcf9e@redhat.com> <20191122180214.GD7448@ziepe.ca> <20191123043951.GA364267@___> <20191123230948.GF7448@ziepe.ca> <20191124145124.GA374942@___> <20191125000919.GB5634@ziepe.ca> From: Jason Wang Message-ID: <1ea2fa65-650e-bb09-f9c6-361dfd9b0b77@redhat.com> Date: Mon, 25 Nov 2019 20:59:42 +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: <20191125000919.GB5634@ziepe.ca> Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-MC-Unique: EC6sypjEMtSlqN8YDpjaPg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On 2019/11/25 =E4=B8=8A=E5=8D=888:09, Jason Gunthorpe wrote: > On Sun, Nov 24, 2019 at 10:51:24PM +0800, Tiwei Bie wrote: > >>>> You removed JasonW's other reply in above quote. He said it clearly >>>> that we do want/need to assign parts of device BAR to the VM. >>> Generally we don't look at patches based on stuff that isn't in them. >> The hardware is ready, and it's something really necessary (for >> the performance). It was planned to be added immediately after >> current series. If you want, it certainly can be included right now. > I don't think it makes a significant difference, there are enough > reasons already that this does not belong in vfio. Both Greg and I > already were very against using mdev as an alterative to the driver > core. Don't get us wrong, in v13 this is what Greg said [1]. " Also, see the other conversations we are having about a "virtual" bus and devices. I do not want to have two different ways of doing the same thing in the kernel at the same time please. Please work together with the Intel developers to solve this in a unified way, as you both need/want the same thing here. Neither this, nor the other proposal can be accepted until you all agree on the design and implementation. " [1] https://lkml.org/lkml/2019/11/18/521 > >>>> IIUC, your point is to suggest us invent new DMA API for userspace to >>>> use instead of leveraging VFIO's well defined DMA API. Even if we don'= t >>>> use VFIO at all, I would imagine it could be very VFIO-like (e.g. caps >>>> for BAR + container/group for DMA) eventually. >>> None of the other user dma subsystems seem to have the problems you >>> are imagining here. Perhaps you should try it first? >> Actually VFIO DMA API wasn't used at the beginning of vhost-mdev. But >> after the discussion in upstream during the RFC stage since the last >> year, the conclusion is that leveraging VFIO's existing DMA API would >> be the better choice and then vhost-mdev switched to that direction. > Well, unfortunately, I think that discussion may have led you > wrong. Do you have a link? Did you post an ICF driver that didn't use vfi= o? Why do you think the driver posted in [2] use vfio? [2] https://lkml.org/lkml/2019/11/21/479 Thanks > > Jason >