Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3409416imm; Sun, 14 Oct 2018 19:50:38 -0700 (PDT) X-Google-Smtp-Source: ACcGV61WKhEWi10YA0kc0m5CXWsDKYocW3YkY3x6VB5b1FB63y7aybWPwZGMRAvsdOVTVBoM5a65 X-Received: by 2002:a63:1f64:: with SMTP id q36-v6mr13897295pgm.88.1539571838918; Sun, 14 Oct 2018 19:50:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539571838; cv=none; d=google.com; s=arc-20160816; b=Ti1N8E64xLngxoA0WDgcWb84NTJjbbzldFKhM+MZRsJzcFD+rDnnRMJMQN7i5O0td7 6OdR/xY7iIvKAOld26JR5HTcyIZGfV0i1OVyGKbzrZ1Kf97pw1jcBUmWEIDkHbiH/A/u 7ogZj7BTrLhT60i8U6EaAYKKjyjNERDfk3Nh8e5sBRqkK2VGixIOLSGVMuZvnf1KzI/B 20/k2QyvgAcRu/NBuUgZPXePojYhi3oLN5RhP6Sm0xKsbmrVfdnECrk5LYR3V0HkVFnP g1Bg81rffsHDcJIqWoQaIpEZU/LVBZKh7A1osH5rIs171tPQTIFbjSCk6+AygUBlUsiq B/+g== 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:to:subject:cc; bh=GmoGMCGS8q4nHqriDVjW6tbpI1HgH0EvB+aKMr721Wg=; b=Q/TRl1E6IvUnwx5bzNt5+iELI4Ls3XGXNJZwSY2Z20OMYHwyX1N7EiU84dy2d8Tqx9 XeviY1YairNEZ3FImsUnJ1sExYW4cF6MkZ67vRPlS1HvGIeRBT+FF5sBkHS3dUOhfINn n6nqnB+DKaSyPM62uviuuiLLr/XvNQKczfcmNJ+0KLceXt3riXV6VOf57AVqlXLv+Brb I7NrhKZJlrQsR4/gc+90tOXGCxW8mWW8HlRmdjgln0ju+6yPJBkWPna+iheOe/0dMcck TCvFhIUdsmTWZLrkvhPxVvdW05eF3rPJYOYmmvIKFZW7YoVWOd0rNF0u2qkJkEHlUxBT GGLA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 8-v6si8899272pgv.137.2018.10.14.19.50.24; Sun, 14 Oct 2018 19:50:38 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726530AbeJOKdP (ORCPT + 99 others); Mon, 15 Oct 2018 06:33:15 -0400 Received: from mga04.intel.com ([192.55.52.120]:9723 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726055AbeJOKdP (ORCPT ); Mon, 15 Oct 2018 06:33:15 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Oct 2018 19:50:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,383,1534834800"; d="scan'208";a="81439003" Received: from allen-box.sh.intel.com (HELO [10.239.161.122]) ([10.239.161.122]) by orsmga008.jf.intel.com with ESMTP; 14 Oct 2018 19:49:58 -0700 Cc: baolu.lu@linux.intel.com, kevin.tian@intel.com, ashok.raj@intel.com, tiwei.bie@intel.com, Jean-Philippe Brucker , sanjay.k.kumar@intel.com, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, yi.y.sun@intel.com, jacob.jun.pan@intel.com, kvm@vger.kernel.org Subject: Re: [PATCH v3 0/8] vfio/mdev: IOMMU aware mediated device To: Xu Zaibo , Joerg Roedel , David Woodhouse , Alex Williamson , Kirti Wankhede References: <20181012051632.26064-1-baolu.lu@linux.intel.com> <5BC1AC09.1060507@huawei.com> From: Lu Baolu Message-ID: Date: Mon, 15 Oct 2018 10:48:04 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5BC1AC09.1060507@huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > 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. Best regards, Lu Baolu