Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1011988ybv; Wed, 5 Feb 2020 19:10:00 -0800 (PST) X-Google-Smtp-Source: APXvYqzAaAl6Nszxz/moSBZS6pDEbGwnRA8ycWu00ccDbU2hGzLWoAmdoGPXSn5HIZkiWnpiSTVL X-Received: by 2002:a05:6830:10a:: with SMTP id i10mr27660862otp.365.1580958600180; Wed, 05 Feb 2020 19:10:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580958600; cv=none; d=google.com; s=arc-20160816; b=XqnFpV02wVAXRLOH64g06+lQfzw3VOWcUG1jcIoSQUQs4fV05LJaBRKT0MwtDDIbt4 ti9Upvdg2KBDzvAGqdCbb3L6HuFKvl7yTPvN05e85WFJqU41NAWRqHTUOXbB+rk1LMXs WlYqTfEhOgk6EfWNWHtUYHj7G9gDy/hZtNxTXbC0Mg7ijl4JbnTjT+WOYC9lvwF87ips 6DMjUWL+LxkexcBOERdUrl5HzowkTvBbCKpjr6tHQLVwDuID+ymC5d/6jxdaEqkcQQvu g6H+fa86qfgcDHDxKF16+i/h3mCv/1S2o+9DxuqJ4fcqn92HiSzondTqg3nsuRrX9v1N lwHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=Ofht4rTASrG2snsF2udWXLpOAWyq8ZOtG/BsyPM5Yj4=; b=cXfQVmELQPRDa440gTL2KmTNjQEa8+tZTqfDt9/L3x/FmsjL/LlyCzvO0I3rSwcqCF D8SWvVTpxC+apMFCyjeqp46dPnos0d0A1xnrpdIJedNX4vKw92TBhT/45h5eR9xcS+FH QYrabS3P4bAZVGXOG0GGiVO9w1EMmURoW2fXH9pXlaJLfQS/bOtJmtyFyY8QrlF+AeDt zuSdfdGvW9hpoCo309vPO8LYd43g4ISrWDdy+6eZBiD2ydNBG9CmWIBrJZCiYnm1Foyt ruUupiFbubVPOrWVkU0QiTy2nDSJZnjps0wAIxbpmn0eavHWqUxAl9KLjTX5XNwwp9c0 ehdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DfArRHpe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c14si1059978otn.118.2020.02.05.19.09.46; Wed, 05 Feb 2020 19:10:00 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DfArRHpe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727793AbgBFDIT (ORCPT + 99 others); Wed, 5 Feb 2020 22:08:19 -0500 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:20556 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727663AbgBFDIT (ORCPT ); Wed, 5 Feb 2020 22:08:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580958498; 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=Ofht4rTASrG2snsF2udWXLpOAWyq8ZOtG/BsyPM5Yj4=; b=DfArRHpeiitC+7vYkkFUGizFqN0yjhjgtOufVxW9kTUXbCB/Om5SjKbw6MIc5udWzDfsjo 39fgfqEZwnYNlVM0YuY8rYXZLgzFWkYdEOXa9CiW4fBTL5T6l7yT5DrxAE50/l78kRInPV 2X07vFi2LJ0rLLX3n/vNDtlAvi3x6ws= 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-79-X7uWwfe4On2D9cXt6zrN6w-1; Wed, 05 Feb 2020 22:08:17 -0500 X-MC-Unique: X7uWwfe4On2D9cXt6zrN6w-1 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8894A107BAA4; Thu, 6 Feb 2020 03:08:14 +0000 (UTC) Received: from [10.72.13.85] (ovpn-13-85.pek2.redhat.com [10.72.13.85]) by smtp.corp.redhat.com (Postfix) with ESMTP id 361F060C18; Thu, 6 Feb 2020 03:07:56 +0000 (UTC) Subject: Re: [PATCH] vhost: introduce vDPA based backend To: "Michael S. Tsirkin" Cc: Shahaf Shuler , Tiwei Bie , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "netdev@vger.kernel.org" , Jason Gunthorpe , "rob.miller@broadcom.com" , "haotian.wang@sifive.com" , "eperezma@redhat.com" , "lulu@redhat.com" , Parav Pandit , "rdunlap@infradead.org" , "hch@infradead.org" , Jiri Pirko , "hanand@xilinx.com" , "mhabets@solarflare.com" , "maxime.coquelin@redhat.com" , "lingshan.zhu@intel.com" , "dan.daly@intel.com" , "cunming.liang@intel.com" , "zhihong.wang@intel.com" References: <20200131033651.103534-1-tiwei.bie@intel.com> <7aab2892-bb19-a06a-a6d3-9c28bc4c3400@redhat.com> <20200205020247.GA368700@___> <112858a4-1a01-f4d7-e41a-1afaaa1cad45@redhat.com> <20200205042259-mutt-send-email-mst@kernel.org> From: Jason Wang Message-ID: <7519cde6-2c79-6867-d72d-05be73d947a6@redhat.com> Date: Thu, 6 Feb 2020 11:07:55 +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: <20200205042259-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/2/5 =E4=B8=8B=E5=8D=885:23, Michael S. Tsirkin wrote: > On Wed, Feb 05, 2020 at 03:50:14PM +0800, Jason Wang wrote: >> On 2020/2/5 =C3=A4=C2=B8=E2=80=B9=C3=A5=C2=8D=CB=863:15, Shahaf Shuler= wrote: >>> Wednesday, February 5, 2020 4:03 AM, Tiwei Bie: >>>> Subject: Re: [PATCH] vhost: introduce vDPA based backend >>>> >>>> On Tue, Feb 04, 2020 at 11:30:11AM +0800, Jason Wang wrote: >>>>> On 2020/1/31 =C3=A4=C2=B8=C5=A0=C3=A5=C2=8D=CB=8611:36, Tiwei Bie w= rote: >>>>>> This patch introduces a vDPA based vhost backend. This backend is >>>>>> built on top of the same interface defined in virtio-vDPA and >>>>>> provides a generic vhost interface for userspace to accelerate the >>>>>> virtio devices in guest. >>>>>> >>>>>> This backend is implemented as a vDPA device driver on top of the >>>>>> same ops used in virtio-vDPA. It will create char device entry nam= ed >>>>>> vhost-vdpa/$vdpa_device_index for userspace to use. Userspace can >>>>>> use vhost ioctls on top of this char device to setup the backend. >>>>>> >>>>>> Signed-off-by: Tiwei Bie >>> [...] >>> >>>>>> +static long vhost_vdpa_do_dma_mapping(struct vhost_vdpa *v) { >>>>>> + /* TODO: fix this */ >>>>> Before trying to do this it looks to me we need the following durin= g >>>>> the probe >>>>> >>>>> 1) if set_map() is not supported by the vDPA device probe the IOMMU >>>>> that is supported by the vDPA device >>>>> 2) allocate IOMMU domain >>>>> >>>>> And then: >>>>> >>>>> 3) pin pages through GUP and do proper accounting >>>>> 4) store GPA->HPA mapping in the umem >>>>> 5) generate diffs of memory table and using IOMMU API to setup the = dma >>>>> mapping in this method >>>>> >>>>> For 1), I'm not sure parent is sufficient for to doing this or need= to >>>>> introduce new API like iommu_device in mdev. >>>> Agree. We may also need to introduce something like the iommu_device= . >>>> >>> Would it be better for the map/umnap logic to happen inside each devi= ce ? >>> Devices that needs the IOMMU will call iommu APIs from inside the dri= ver callback. >> Technically, this can work. But if it can be done by vhost-vpda it wil= l make >> the vDPA driver more compact and easier to be implemented. >> >> >>> Devices that has other ways to do the DMA mapping will call the propr= ietary APIs. >> To confirm, do you prefer: >> >> 1) map/unmap >> >> or >> >> 2) pass all maps at one time? >> >> Thanks >> >> > I mean we really already have both right? ATM 1 is used with an iommu > and 2 without. I guess we can also have drivers ask for either or both > ... Yes, that looks better. Thanks