Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp76831ybz; Thu, 16 Apr 2020 19:47:17 -0700 (PDT) X-Google-Smtp-Source: APiQypKo0EUOpVRj1fGDKXcmIcleJ0qG/BO3EcTk25/L7lBak5ehGvHDtjZEZ0F06nAjOUn1DHrS X-Received: by 2002:a17:907:42d6:: with SMTP id ng6mr947948ejb.265.1587091637636; Thu, 16 Apr 2020 19:47:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587091637; cv=none; d=google.com; s=arc-20160816; b=onnGff/1F7UndJ8GE19hayQSGsaVvM7DfP067DTC8Q2TiDq1y6li7OeLMxDJIvinNW xDKMiDypuKOsoOBOkrkICdCb4nu3gVrmufAZUYNr7rBMBpl7v+bSaqZjvvyp4ebaV/fl t7EWgfpxu3u36rqMqtybeAQgxlV1iyWQdYWfh/ef59Z+BB++D41DO0U+aKaeGIXwW3Yw TKAiSa024FY40Q5ZchlrjE2GgGCvIkFlNOaUSif4oQ8is5NKjjNRBJO19MrAPqgIsFLw D8HjqhY0kOMRPwz+ymcPP8+EvCnGUbhoVgAJyKKpJoYlM5wuDWukN8KiEPa6OjXaMzrO aCLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :dlp-reaction:dlp-version:dlp-product:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from:ironport-sdr:ironport-sdr; bh=tXM2WandVCoH8HGS+7od1ewDxPLrv1PN5NfEp2SPDac=; b=b2ifOaqp0ckp2CkaTDemlesy79a1Y2gtLgv/Rq92tYuofA+OeSGNgrjEGyDiMisg7b RZVAEVn7q8B1Az0oN1ZUSwghzKQc39ETsFIxfaNk8tO11WPDGWJDTzh3k7B7Zgc7HYFt fbvuWDk2cl5zf92jSCGTzhQNjW3Of5PBzI74e0p1UKkOxhycE5JBWVgMBWOkrIzJmN2P Lj9cZUJ9lqMes9+eoJcXxkZuDH4OUVlnCnJRQYWX4/tnT/M8nb/cHZyvDMmUbvbgfx1/ RQyu3HYP5uuLl96BK7HxHRxG90Nz8E69DywJ5kZ/g12GFzsEQI2uQIck5TEXoouM8dhY Kbew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id z72si14661801ede.95.2020.04.16.19.46.54; Thu, 16 Apr 2020 19:47:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1729292AbgDQCpd convert rfc822-to-8bit (ORCPT + 99 others); Thu, 16 Apr 2020 22:45:33 -0400 Received: from mga09.intel.com ([134.134.136.24]:54975 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728364AbgDQCpd (ORCPT ); Thu, 16 Apr 2020 22:45:33 -0400 IronPort-SDR: v9A73oWHJ7U3Kc97Wo0563K9l+A/HORpuIPJw0J2ivwwmOUYdpxhBuapbiuS4VmJbyAFHAjwL9 usDf7YuYa8Fg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2020 19:45:32 -0700 IronPort-SDR: eCPijPNfhNoemscwgxRcefwZ2Y8SDR6sV++TqTEKQKEU4t7fpT3657DIOrOonPGx1svabfdC4R GFebdUbl5iyQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,393,1580803200"; d="scan'208";a="278222332" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga004.fm.intel.com with ESMTP; 16 Apr 2020 19:45:32 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 16 Apr 2020 19:45:32 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 16 Apr 2020 19:45:32 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.225]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.129]) with mapi id 14.03.0439.000; Fri, 17 Apr 2020 10:45:23 +0800 From: "Tian, Kevin" To: Auger Eric , Jacob Pan CC: Yi L , Alex Williamson , "Raj, Ashok" , "David Woodhouse" , LKML , "iommu@lists.linux-foundation.org" , Jean-Philippe Brucker , Jonathan Cameron Subject: RE: [PATCH v11 05/10] iommu/vt-d: Add bind guest PASID support Thread-Topic: [PATCH v11 05/10] iommu/vt-d: Add bind guest PASID support Thread-Index: AQHWCebOp12IiW87IUSByO2zgM/w7qhv6qkAgAJcu4CACNZVgIABkaSw Date: Fri, 17 Apr 2020 02:45:22 +0000 Message-ID: References: <1585939334-21396-1-git-send-email-jacob.jun.pan@linux.intel.com> <1585939334-21396-6-git-send-email-jacob.jun.pan@linux.intel.com> <20200410124557.4012b99b@jacob-builder> <6d9721a8-2198-5ecd-6c8b-fc43ff2ad7e1@redhat.com> In-Reply-To: <6d9721a8-2198-5ecd-6c8b-fc43ff2ad7e1@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > From: Auger Eric > Sent: Thursday, April 16, 2020 6:43 PM > [...] > >>> + if (svm) { > >>> + /* > >>> + * If we found svm for the PASID, there must be at > >>> + * least one device bond, otherwise svm should be > >>> freed. > >>> + */ > >>> + if (WARN_ON(list_empty(&svm->devs))) { > >>> + ret = -EINVAL; > >>> + goto out; > >>> + } > >>> + > >>> + for_each_svm_dev(sdev, svm, dev) { > >>> + /* In case of multiple sub-devices of the > >>> same pdev > >>> + * assigned, we should allow multiple bind > >>> calls with > >>> + * the same PASID and pdev. > >>> + */ > >>> + sdev->users++; > >> What if this is not an mdev device. Is it also allowed? > > Yes. IOMMU and VT-d driver is not mdev aware. Here mdev is just an > > example of normal use case. You can bind the same PCI device (PF or > > SRIOV VF) more than once to the same PASID. Just need to unbind also. > > I don't get the point of binding a non mdev device several times with > the same PASID. Do you intend to allow that at userspace level or > prevent this from happening in VFIO? I feel it's better to prevent this from happening, otherwise VFIO also needs to track the bind count and do multiple unbinds at mm_exit. But it's not necessary to prevent it in VFIO. We can check here upon whether aux_domain is valid, and if not return -EBUSY. > > Besides, the comment is a bit misleading as it gives the impression it > is only true for mdev and there is no associated check. Thanks Kevin