Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3661763imm; Mon, 15 Oct 2018 01:51:20 -0700 (PDT) X-Google-Smtp-Source: ACcGV60JlJ4OAuBFvMZwfb145ViqtOWZr6xBBdGNcLRfAsJhgDZkAMFjWSYQHXNjIGAjtT96ECk7 X-Received: by 2002:a62:2c16:: with SMTP id s22-v6mr16655727pfs.6.1539593480124; Mon, 15 Oct 2018 01:51:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539593480; cv=none; d=google.com; s=arc-20160816; b=h8Ll1A4g/kpzXBRtLBn7/iuEfBxPENgaNx+QtPzJwj49M+1tUSA0IfobZpxE642tjR fmCEk6K+eda1sO+d/agd9j+LeltfqEyirSCFCx6hcSiR8f49KRjooyTB26nGFvlcYXNg /jHvit8HKbscu1Wj9iPIkPFkHlW6OqLdAFKH0B+h9d6EG8jHZMoHgDECkKuR+7RTxSzi DDymhw1CuXaablEBraXvs6Hmk0CqYjExHAjdRDOQQvWc52b3I2qBmjtJ4d15gVzabzlF 4PwFJJFs/hBu4ETzqHdWedBlbRIoLOSOT2O/ffGqopkvDd5fzmXm9nxm9BPFRq9mvIjr 8ERQ== 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:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=20jWjVsg1OWXq2iZE/Uj2UtHsr50ape5JW4EAEYAbOg=; b=0vqBCs4OgGEMpkstU7ASetg5KsdkjwgKcWnZmzuPwaidkhBRT0WWiRqCDsJJIcOVSJ 8cyKa8CiUEYlovCSz/PvVVxFJOcAEHqCF5ejOXiATFzZvrIr7Qm8j1Umm5IPPOhoWHzg pf2Vx5Q6Pmmy91cjxNLb/xuyfyXbGmzXS6pVIf+c34sbpTvy4zL3Nej2+iIVTQdgFElw bhQ7nMZE6EpipgSZgYnxivHBL40lucnAb2OPL1YUInSd9UbDV5jCB+9Dprj9mZZpw1bZ Phw6M7dMSQMjyqJuIUBTgj9fKAe/hHgx5omSzWmCrYEx3zj6gp5fGfarQtbJz6TclyR9 2S1g== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q19-v6si10181467pll.286.2018.10.15.01.51.04; Mon, 15 Oct 2018 01:51:20 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726566AbeJOQfC (ORCPT + 99 others); Mon, 15 Oct 2018 12:35:02 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:13635 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726319AbeJOQfC (ORCPT ); Mon, 15 Oct 2018 12:35:02 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 74DC114452CD8; Mon, 15 Oct 2018 16:50:39 +0800 (CST) Received: from [127.0.0.1] (10.57.77.109) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.399.0; Mon, 15 Oct 2018 16:50:40 +0800 Subject: Re: [PATCH v3 0/8] vfio/mdev: IOMMU aware mediated device To: Lu Baolu , Joerg Roedel , "David Woodhouse" , Alex Williamson , Kirti Wankhede References: <20181012051632.26064-1-baolu.lu@linux.intel.com> <5BC1AC09.1060507@huawei.com> CC: , , , Jean-Philippe Brucker , , , , , , From: Xu Zaibo Message-ID: <5BC454DF.6010109@huawei.com> Date: Mon, 15 Oct 2018 16:50:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.57.77.109] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 2018/10/15 10:48, Lu Baolu wrote: > Hi, > > On 10/13/2018 04:25 PM, Xu Zaibo wrote: >> Hi, >> >> On 2018/10/12 13:16, Lu Baolu wrote: >>> Hi, >>> >>> The Mediate Device is a framework for fine-grained physical device >>> sharing across the isolated domains. Currently the mdev framework >>> is designed to be independent of the platform IOMMU support. As the >>> result, the DMA isolation relies on the mdev parent device in a >>> vendor specific way. >>> >>> There are several cases where a mediated device could be protected >>> and isolated by the platform IOMMU. For example, Intel vt-d rev3.0 >>> [1] introduces a new translation mode called 'scalable mode', which >>> enables PASID-granular translations. The vt-d scalable mode is the >>> key ingredient for Scalable I/O Virtualization [2] [3] which allows >>> sharing a device in minimal possible granularity (ADI - Assignable >>> Device Interface). >>> >>> A mediated device backed by an ADI could be protected and isolated >>> by the IOMMU since 1) the parent device supports tagging an unique >>> PASID to all DMA traffic out of the mediated device; and 2) the DMA >>> translation unit (IOMMU) supports the PASID granular translation. >>> We can apply IOMMU protection and isolation to this kind of devices >>> just as what we are doing with an assignable PCI device. >>> >>> In order to distinguish the IOMMU-capable mediated devices from those >>> which still need to rely on parent devices, this patch set adds two >>> new members in struct mdev_device. >>> >>> * iommu_device >>> - This, if set, indicates that the mediated device could >>> be fully isolated and protected by IOMMU via attaching >>> an iommu domain to this device. If empty, it indicates >>> using vendor defined isolation. >>> >>> * iommu_domain >>> - This is a place holder for an iommu domain. A domain >>> could be store here for later use once it has been >>> attached to the iommu_device of this mdev. >>> >>> Below helpers are added to set and get above iommu device >>> and iommu domain pointers in mdev core implementation. >>> >>> * mdev_set/get_iommu_device(dev, iommu_device) >>> - Set or get the iommu device which represents this mdev >>> in IOMMU's device scope. Drivers don't need to set the >>> iommu device if it uses vendor defined isolation. >>> >>> * mdev_set/get_iommu_domain(domain) >>> - A iommu domain which has been attached to the iommu >>> device in order to protect and isolate the mediated >>> device will be kept in the mdev data structure and >>> could be retrieved later. >>> >>> The mdev parent device driver could opt-in that the mdev could be >>> fully isolated and protected by the IOMMU when the mdev is being >>> created by invoking mdev_set_iommu_device() in its @create(). >> I just cannot understand here, how to get an iommu_device while I >> create mediated >> device in my parent device driver? > > When you are creating an mdev in your parent driver, you should know > which PCI device this mdev belonging to. > So, generally, I can set the parent device as mdev's iommu_device? If that, however, Mdev already holds its parent device. So, I just figure what differences between Mdev's parent device and iommu_device are. >> >> And why not reuse the device of MDEV instread of adding a new device >> here? > > iommu_device in the mdev_device structure represents the PCI device > that represents this mdev in iommu's device scope. IOMMU is only aware > of pci devices, it's not aware of mdev device. Could I understand like that: IOMMU can be aware of the parent device of Mdev? And more, I am doubting the necessary of iommu_device in Mdev. Thanks, Zaibo .