Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp123960rdb; Mon, 18 Sep 2023 09:53:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHhdS1sG/uebLsvxxA1o/1jIxQsjYmKPaK7PVEKrxcIv2ItrG6BHGQURF4YZPZ6K97w070o X-Received: by 2002:a05:6808:1282:b0:3a9:ba39:6d6a with SMTP id a2-20020a056808128200b003a9ba396d6amr14033952oiw.21.1695056030743; Mon, 18 Sep 2023 09:53:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695056030; cv=none; d=google.com; s=arc-20160816; b=NAyd8TdrhXOLfrrXFylGFHwBNPGEkOxw1Q6fmkWxPO+/rqBmnKzJvhcfqDBCoQiPdz L4zYqLKMX1qhNMSukdGZ4wo8vjbqNYAsWrONGewAb3MND65zWc7uT6gvpl9Xycws9ZGn JbEx63bWusFoTzIMR69ySjRbg42S/VIg0WonkHF3VcKddGVNlQVf39RwJptkcq0bs0Jx +5RxzKA/vaR5MmrdKl5fJrXW2maJL5EFZZRmnbv8boElTNy0jNIBlxC7XjDRlmnKiTsG S3U8jAuqpYGXcMl6hkb2on0DDUr3tASjJHq59Pg1v+nNDQy0TOVwgTcx4op6+fj7TlPr 4jfw== 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=Vwqm6X40vJpGv0L/WQU1+xviKksG0xlxxIi7E7y13Nc=; fh=tXED96nHPrcQBTQkoUCcFTE7+93KukO2qBvskM8PeTE=; b=wN7q+aVI5I7IdvJpkEpJ1uglBveWrd2Tif6Y2eHJKxGpReMdPHaqbpzyKQ3CpJZG1B wxajsch9hC1fRzygt7iKeHWK4tMeUO/qF1bJCpEtrltOHoC1EO0TPYK98vah9fQZqMy5 LzKUOt7GVputZe4Ragy8Crmklu41a2MMt6FfvtCtWz/DvaXhyWBbXXls8aWFDMK/Ddxu mtUyM4z+Xhe+aOyTJzs2CFgbGuO9blWsiStGaf4gmIqbld4+uXrayqbiQ7U37iW+aACO 6HS9owqmJqrfUTL7p8aq17W9PS5wKK2j6YAbmKEOqpq5EAxsH57rzyDhllaml+j58Y7H IOpA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 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 agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id i63-20020a638742000000b0056a45e2b40bsi8130416pge.639.2023.09.18.09.53.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Sep 2023 09:53:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 9C18A80190AC; Mon, 18 Sep 2023 09:41:45 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230329AbjIRQli (ORCPT + 99 others); Mon, 18 Sep 2023 12:41:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230305AbjIRQlM (ORCPT ); Mon, 18 Sep 2023 12:41:12 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0B8E349E2 for ; Mon, 18 Sep 2023 09:37:54 -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 A9BDF1FB; Mon, 18 Sep 2023 09:38:31 -0700 (PDT) Received: from [10.57.94.165] (unknown [10.57.94.165]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2DBE53F59C; Mon, 18 Sep 2023 09:37:53 -0700 (PDT) Message-ID: Date: Mon, 18 Sep 2023 17:37:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v2 1/2] iommu/virtio: Make use of ops->iotlb_sync_map Content-Language: en-GB To: Niklas Schnelle , Jean-Philippe Brucker , Joerg Roedel , Will Deacon Cc: virtualization@lists.linux-foundation.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org References: <20230918-viommu-sync-map-v2-0-f33767f6cf7a@linux.ibm.com> <20230918-viommu-sync-map-v2-1-f33767f6cf7a@linux.ibm.com> From: Robin Murphy In-Reply-To: <20230918-viommu-sync-map-v2-1-f33767f6cf7a@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Mon, 18 Sep 2023 09:41:45 -0700 (PDT) On 2023-09-18 12:51, Niklas Schnelle wrote: > Pull out the sync operation from viommu_map_pages() by implementing > ops->iotlb_sync_map. This allows the common IOMMU code to map multiple > elements of an sg with a single sync (see iommu_map_sg()). Furthermore, > it is also a requirement for IOMMU_CAP_DEFERRED_FLUSH. Is it really a requirement? Deferred flush only deals with unmapping. Or are you just trying to say that it's not too worthwhile to try doing more for unmapping performance while obvious mapping performance is still left on the table? > Link: https://lore.kernel.org/lkml/20230726111433.1105665-1-schnelle@linux.ibm.com/ > Signed-off-by: Niklas Schnelle > --- > drivers/iommu/virtio-iommu.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c > index 17dcd826f5c2..3649586f0e5c 100644 > --- a/drivers/iommu/virtio-iommu.c > +++ b/drivers/iommu/virtio-iommu.c > @@ -189,6 +189,12 @@ static int viommu_sync_req(struct viommu_dev *viommu) > int ret; > unsigned long flags; > > + /* > + * .iotlb_sync_map and .flush_iotlb_all may be called before the viommu > + * is initialized e.g. via iommu_create_device_direct_mappings() > + */ > + if (!viommu) > + return 0; Minor nit: I'd be inclined to make that check explicitly in the places where it definitely is expected, rather than allowing *any* sync to silently do nothing if called incorrectly. Plus then they could use vdomain->nr_endpoints for consistency with the equivalent checks elsewhere (it did take me a moment to figure out how we could get to .iotlb_sync_map with a NULL viommu without viommu_map_pages() blowing up first...) Thanks, Robin. > spin_lock_irqsave(&viommu->request_lock, flags); > ret = __viommu_sync_req(viommu); > if (ret) > @@ -843,7 +849,7 @@ static int viommu_map_pages(struct iommu_domain *domain, unsigned long iova, > .flags = cpu_to_le32(flags), > }; > > - ret = viommu_send_req_sync(vdomain->viommu, &map, sizeof(map)); > + ret = viommu_add_req(vdomain->viommu, &map, sizeof(map)); > if (ret) { > viommu_del_mappings(vdomain, iova, end); > return ret; > @@ -912,6 +918,14 @@ static void viommu_iotlb_sync(struct iommu_domain *domain, > viommu_sync_req(vdomain->viommu); > } > > +static int viommu_iotlb_sync_map(struct iommu_domain *domain, > + unsigned long iova, size_t size) > +{ > + struct viommu_domain *vdomain = to_viommu_domain(domain); > + > + return viommu_sync_req(vdomain->viommu); > +} > + > static void viommu_get_resv_regions(struct device *dev, struct list_head *head) > { > struct iommu_resv_region *entry, *new_entry, *msi = NULL; > @@ -1058,6 +1072,7 @@ static struct iommu_ops viommu_ops = { > .unmap_pages = viommu_unmap_pages, > .iova_to_phys = viommu_iova_to_phys, > .iotlb_sync = viommu_iotlb_sync, > + .iotlb_sync_map = viommu_iotlb_sync_map, > .free = viommu_domain_free, > } > }; >