Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2489941pxp; Mon, 21 Mar 2022 22:21:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx3rqq1Bpx9w/PAAOaqUtpfCBKPvCAqZjVd2QAIxr/vitCtoXg2LVmlIJKdrqSiCujMb+5A X-Received: by 2002:a05:6a00:1ca1:b0:4fa:7e80:6957 with SMTP id y33-20020a056a001ca100b004fa7e806957mr15729636pfw.33.1647926500709; Mon, 21 Mar 2022 22:21:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647926500; cv=none; d=google.com; s=arc-20160816; b=wP4i7J2T/hJrzfB0yKt25l/3Tn46vAPaSv3xqLl1IAChEkltE+L0m5E93Pe6N7V1/v Wt6amjwth0oEGCCzjvffG43pqQu8ug8lL24Db7UudDerRGw8wW1VsJX68FtlOYa4+DIg u9j2Pt4w0EPJa1Z0p1gSzhMZsPPyhwwtJms9F2lZUTbJK5ljm1Cet+9kHyxhbsKMX+KZ 0i56zo7IC578Y0jnXFlN3ud2bArz7xDO7kooOU+R5ZVWZSCZmVUcA2/Fwip1QS6PyuEg ANT4M5rIgrbgZDTZPUV6Ef5DH8pfJzM5o1OwPoTSN/HQ3WmA2e5ALot27TJwsXa6ADlY 4fUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:content-language:subject:cc:user-agent:mime-version :date:message-id:dkim-signature; bh=WIobDBgNMCz/qciqwqfcuSsea7RTUfZd5CHfJ7cmeNk=; b=yzZzWI8M93Rd6aGbN6HMGxtI5wkdObzG8aN5Eyc1UxVBLUeASp58k0Ci4hnL9LXd5A WgJmIvprO0SjBZWuSBVjbCJPHL2n0W1zH7Pu59dI9w1LUz+RBrqPRCyhcflRrKi/F4Xp sZIotau5fWJQC6TbrxZtCnRmcf/YpwKRzX3w5J3kw2bhFkVF4mGp83F63yYDEmYRdfbs ZTPaQqkcG9l4qE1f2lOABwduTHxukSPBgThoNAlY+qHCbYUEXa0e7VeyA/4nyvffORPp 3ZSkatFX/R/1DUOAUSXGOMSF8hWu4cQQw34UabnP0Rbh1PzLTt78cyJYZ3RzSFx+FGSb BvVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ck+BZ7PL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id e9-20020a170902e0c900b00153b2d164b6si11661276pla.190.2022.03.21.22.21.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Mar 2022 22:21:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ck+BZ7PL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 71A0B193F3; Mon, 21 Mar 2022 21:29:59 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236425AbiCVEbQ (ORCPT + 99 others); Tue, 22 Mar 2022 00:31:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55186 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236363AbiCVEbP (ORCPT ); Tue, 22 Mar 2022 00:31:15 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F38B1408C for ; Mon, 21 Mar 2022 21:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647923387; x=1679459387; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=e1W86sXEli1RnC50Lifh7zwKkpipBaeccg3PcImsLsw=; b=ck+BZ7PLCOdFTPPGI353q+vIdU+Plw81S5dz1ka9z6sd7x7coJ2NYX0p pVfZQK8YL7NP0iU0nS/ijUy777rx1E/GpUDbb267he4wzycYIAIuaFnl5 zwRYlrKRzUQ/TDQ/TaMoW7i8BS/Z3Bc1Rw2UVyKnW80EyGL8O4qoTYQqN N2Ej8RWHRrzxkgL6InM02eaYdRIgkcwYiAZ8w24ZiC4fObi/tUsRMK3mJ F20vj58msuA8QtMLdyq0mafa9HB19AYo1UktJRSLRP5uFr1vKl9G3CmFn EkE7fgz75dAgokKC4dSepDwbg8LUiHLSPWTt31QhHn5jiQim32F1SrO98 A==; X-IronPort-AV: E=McAfee;i="6200,9189,10293"; a="257667672" X-IronPort-AV: E=Sophos;i="5.90,200,1643702400"; d="scan'208";a="257667672" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Mar 2022 21:29:47 -0700 X-IronPort-AV: E=Sophos;i="5.90,200,1643702400"; d="scan'208";a="518718729" Received: from blu2-mobl3.ccr.corp.intel.com (HELO [10.254.209.186]) ([10.254.209.186]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Mar 2022 21:29:42 -0700 Message-ID: Date: Tue, 22 Mar 2022 12:29:40 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Cc: baolu.lu@linux.intel.com, Joerg Roedel , Jason Gunthorpe , Christoph Hellwig , Kevin Tian , Ashok Raj , Will Deacon , Robin Murphy , Jean-Philippe Brucker , Eric Auger , Liu Yi L , Jacob jun Pan , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC 06/11] iommu/sva: Use attach/detach_pasid_dev in SVA interfaces Content-Language: en-US To: Jean-Philippe Brucker References: <20220320064030.2936936-1-baolu.lu@linux.intel.com> <20220320064030.2936936-7-baolu.lu@linux.intel.com> From: Lu Baolu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/3/21 19:33, Jean-Philippe Brucker wrote: > On Sun, Mar 20, 2022 at 02:40:25PM +0800, Lu Baolu wrote: >> diff --git a/drivers/iommu/iommu-sva-lib.c b/drivers/iommu/iommu-sva-lib.c >> index 106506143896..47cf98e661ff 100644 >> --- a/drivers/iommu/iommu-sva-lib.c >> +++ b/drivers/iommu/iommu-sva-lib.c >> @@ -3,6 +3,8 @@ >> * Helpers for IOMMU drivers implementing SVA >> */ >> #include >> +#include >> +#include >> #include >> >> #include "iommu-sva-lib.h" >> @@ -69,3 +71,101 @@ struct mm_struct *iommu_sva_find(ioasid_t pasid) >> return ioasid_find(&iommu_sva_pasid, pasid, __mmget_not_zero); >> } >> EXPORT_SYMBOL_GPL(iommu_sva_find); >> + >> +static struct iommu_domain *iommu_sva_domain_alloc(struct device *dev) >> +{ >> + struct bus_type *bus = dev->bus; >> + struct iommu_domain *domain; >> + >> + if (!bus || !bus->iommu_ops) >> + return NULL; >> + >> + domain = bus->iommu_ops->domain_alloc(IOMMU_DOMAIN_SVA); >> + if (domain) >> + domain->type = IOMMU_DOMAIN_SVA; >> + >> + return domain; >> +} >> + >> +/** >> + * iommu_sva_bind_device() - Bind a process address space to a device >> + * @dev: the device >> + * @mm: the mm to bind, caller must hold a reference to it >> + * @drvdata: opaque data pointer to pass to bind callback >> + * >> + * Create a bond between device and address space, allowing the device to access >> + * the mm using the returned PASID. If a bond already exists between @device and >> + * @mm, it is returned and an additional reference is taken. > This is not true anymore, we return a different structure for each call. > >> Caller must call >> + * iommu_sva_unbind_device() to release each reference. >> + * >> + * iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) must be called first, to >> + * initialize the required SVA features. >> + * >> + * On error, returns an ERR_PTR value. >> + */ >> +struct iommu_sva * >> +iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, void *drvdata) >> +{ >> + int ret = -EINVAL; >> + struct iommu_sva *handle; >> + struct iommu_domain *domain; >> + >> + handle = kzalloc(sizeof(*handle), GFP_KERNEL); >> + if (!handle) >> + return ERR_PTR(-ENOMEM); >> + >> + ret = iommu_sva_alloc_pasid(mm, 1, (1U << dev->iommu->pasid_bits) - 1); >> + if (ret) >> + goto out; >> + >> + domain = iommu_sva_domain_alloc(dev); >> + if (!domain) { >> + ret = -ENOMEM; >> + goto out; >> + } >> + domain->sva_cookie = mm; >> + >> + ret = iommu_attach_device_pasid(domain, dev, mm->pasid); >> + if (ret) >> + goto out_free_domain; >> + >> + handle->dev = dev; >> + handle->domain = domain; >> + handle->pasid = mm->pasid; >> + >> + return handle; >> + >> +out_free_domain: >> + iommu_domain_free(domain); >> +out: >> + kfree(handle); >> + >> + return ERR_PTR(ret); >> +} >> +EXPORT_SYMBOL_GPL(iommu_sva_bind_device); >> + >> +/** >> + * iommu_sva_unbind_device() - Remove a bond created with iommu_sva_bind_device >> + * @handle: the handle returned by iommu_sva_bind_device() >> + * >> + * Put reference to a bond between device and address space. > Same here. But I'd prefer keeping the old behavior so device drivers don't > have to keep track of {dev, mm} pairs themselves. Okay. Thank you for pointing this out. Let me figure it out in the next version. Best regards, baolu