Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2955360ioo; Tue, 24 May 2022 09:35:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwu08vAVzB2TPtbJzrp8igOCoKVyOko/P1ew3blegBVfEmattYMJsh/vAZ2qj4MXJgkjYdK X-Received: by 2002:a05:6402:2996:b0:42b:49a:6d24 with SMTP id eq22-20020a056402299600b0042b049a6d24mr27138958edb.145.1653410140537; Tue, 24 May 2022 09:35:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653410140; cv=none; d=google.com; s=arc-20160816; b=kgcxVw8Dj6cjdiQGCx/E3Pkal91ARabH0xXNlh7WUmFExZGchpS3uXYiJSl3UMaP7D iBIM82yh9+BSJyFQzjWcf3NYxqRLjuvarOCzzTJnblSY0UM1WS/dUIi44ufPSLmeZZbK UftJ4P+KwYk5GJtU+A+gsk8381V4VvTSBST1Jtwa78mLx+MdN/wwSuwq4XxepW/qvJ4n Z+fA6oRH1HEhDh7daM4tSHnknp4u+qsheoKMfPA6a0QEEZjmrIgoW9khhJs1GIjkN4Te zr03yvT2SR8ZIrAdsQfgs07Jhtx3tDu75oW0I0cwPkN43YXw8tiYKrkv6+OdeCp8vQVn GI0Q== 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:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=9Ms7XW8MtBszri5DjzAKbTD16hyGkfB4CbCNFPn8gQM=; b=FGY7AVS7b3yz5JZ+BJ559QqmqCOjJtHLopUR0j47lZobxJMvppZaRWQH/3xOBrkVzA 0XsF6OrSIz/dF4Vgm9JFbo4Mx+p4x0dFWyztLS/sVGXgjumvTieEpOw/vWmuQwu/BwtZ dJ0OoCaSTnEcOQSGr8dpajglLOQPMgoFdvijjgxo7E3/wTwmC3n57EHZqc4vKoD8GTVM GH4fShoJBX8Zn4o8mHJUxpDBBpVSDd95CsVc05kOzO3uSDJmsDmU0IL1HIxQnnRXmDP7 PX1jfr4aj3JXEPmkOwBPtyrxws9K8tu0hYnj479qPcmvtJV4g0+PDehEnxyD3YdtzB0y Nelg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qk16-20020a1709077f9000b006f863e61b2esi2288262ejc.563.2022.05.24.09.35.13; Tue, 24 May 2022 09:35:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238271AbiEXOgX (ORCPT + 99 others); Tue, 24 May 2022 10:36:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236719AbiEXOgW (ORCPT ); Tue, 24 May 2022 10:36:22 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C06E150E0B for ; Tue, 24 May 2022 07:36:20 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2FD9F1FB; Tue, 24 May 2022 07:36:20 -0700 (PDT) Received: from [10.57.82.55] (unknown [10.57.82.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1E7193F66F; Tue, 24 May 2022 07:36:17 -0700 (PDT) Message-ID: Date: Tue, 24 May 2022 15:36:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH v7 03/10] iommu/sva: Add iommu_sva_domain support Content-Language: en-GB To: Lu Baolu , Joerg Roedel , Jason Gunthorpe , Christoph Hellwig , Kevin Tian , Ashok Raj , Will Deacon , Jean-Philippe Brucker , Dave Jiang , Vinod Koul Cc: Jean-Philippe Brucker , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Jacob jun Pan References: <20220519072047.2996983-1-baolu.lu@linux.intel.com> <20220519072047.2996983-4-baolu.lu@linux.intel.com> From: Robin Murphy In-Reply-To: <20220519072047.2996983-4-baolu.lu@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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-05-19 08:20, Lu Baolu wrote: [...] > diff --git a/drivers/iommu/iommu-sva-lib.c b/drivers/iommu/iommu-sva-lib.c > index 106506143896..210c376f6043 100644 > --- a/drivers/iommu/iommu-sva-lib.c > +++ b/drivers/iommu/iommu-sva-lib.c > @@ -69,3 +69,51 @@ 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); > + > +/* > + * IOMMU SVA driver-oriented interfaces > + */ > +struct iommu_domain * > +iommu_sva_alloc_domain(struct bus_type *bus, struct mm_struct *mm) Argh, please no new bus-based external interfaces! Domain allocation needs to resolve to the right IOMMU instance to solve a number of issues, and cleaning up existing users of iommu_domain_alloc() to prepare for that is already hard enough. This is arguably even more relevant here than for other domain types, since SVA support is more likely to depend on specific features that can vary between IOMMU instances even with the same driver. Please make the external interface take a struct device, then resolve the ops through dev->iommu. Further nit: the naming inconsistency bugs me a bit - iommu_sva_domain_alloc() seems more natural. Also I'd question the symmetry vs. usability dichotomy of whether we *really* want two different free functions for a struct iommu_domain pointer, where any caller which might mix SVA and non-SVA usage then has to remember how they allocated any particular domain :/ > +{ > + struct iommu_sva_domain *sva_domain; > + struct iommu_domain *domain; > + > + if (!bus->iommu_ops || !bus->iommu_ops->sva_domain_ops) > + return ERR_PTR(-ENODEV); > + > + sva_domain = kzalloc(sizeof(*sva_domain), GFP_KERNEL); > + if (!sva_domain) > + return ERR_PTR(-ENOMEM); > + > + mmgrab(mm); > + sva_domain->mm = mm; > + > + domain = &sva_domain->domain; > + domain->type = IOMMU_DOMAIN_SVA; > + domain->ops = bus->iommu_ops->sva_domain_ops; I'd have thought it would be logical to pass IOMMU_DOMAIN_SVA to the normal domain_alloc call, so that driver-internal stuff like context descriptors can be still be hung off the domain as usual (rather than all drivers having to implement some extra internal lookup mechanism to handle all the SVA domain ops), but that's something we're free to come back and change later. FWIW I'd just stick the mm pointer in struct iommu_domain, in a union with the fault handler stuff and/or iova_cookie - those are mutually exclusive with SVA, right? Cheers, Robin. > + > + return domain; > +} > + > +void iommu_sva_free_domain(struct iommu_domain *domain) > +{ > + struct iommu_sva_domain *sva_domain = to_sva_domain(domain); > + > + mmdrop(sva_domain->mm); > + kfree(sva_domain); > +} > +