Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp497863rdb; Tue, 19 Sep 2023 01:30:49 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFstULc+9yAFZzgmzCo/ktFzkoPLQKTgcsyKI9bCj7BKIB1WL6GEfqZXFFAsP3H/zsgdKPx X-Received: by 2002:a05:6358:9217:b0:13a:a85b:c373 with SMTP id d23-20020a056358921700b0013aa85bc373mr11718771rwb.18.1695112249259; Tue, 19 Sep 2023 01:30:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695112249; cv=none; d=google.com; s=arc-20160816; b=rpcqbOq5tayRlgXQDzFgNsyyVcFZ2Uttz367lv8IC57LYjG5a7US3407AaH1grXcqD D4xI93gybX0vpfChelf/x0Y4t0AEpP2QzDt86PwYr3lO7aMe6cfawu9ijb95Ih6CWL25 dpG9I8LVBRi+pTtFPXBco72Dlu3ScTBi3eFoq/XZQJLo/9Vsz7+fI4ECcJyuSzqvw1Ip sOHT2Pv+umR63NZzTZnkVUIpSVGFPq0cBpIdFpqgZS/VQ6CDior9DZfQaecf3yhf9MSf fq/9QPnzLK1kS8HAVT6XJzvKwcnWcy5Eysk9Ogtdpb80107SyVjfvQMfpVfdveDorAvG p4MQ== 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=wz02G+UR1ty6K//Qpq/15/bqNdtC0wLWggnc4LbsdY0=; fh=psLn/9wsRYdc33cxREfyO0UI7cv9OWMm7tImZaI6uRA=; b=aDp24vKf2ygSWlKqQsDLLEk2DkMlaIfUheqaILH1bFrKPQ+o1ObVL7ctMvk605oEyO qVlUI6tNx4NxotGYiI89dwpQsxPo+IyRQ7VqJxlEaPSExreKrofaqk0CKdEUsfQ1RzoZ cMBN2HAw/xgyhuadvHoe1eTx8HrdsEhxHQzB4lhL8SiocFuGOLb+j/WQRXdTgI3/pQLR /Y/pL8+c53YTUVJcdui2T6I2MR49CqiwnL+H4gZB/SyAmBPXPY15mDNyHQUzOwAUItLQ qyAdKEH/6Swj8Sinf3ho6kMbv6DC/dhc6sJqGgJPDMrJDYZDqb+ilvMdM91KsSsBzZ0O qK2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 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 fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id x5-20020a654145000000b00578b9314261si598078pgp.437.2023.09.19.01.30.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Sep 2023 01:30:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 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 fry.vger.email (Postfix) with ESMTP id 4E6D48227908; Tue, 19 Sep 2023 01:28:34 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231137AbjISI2W (ORCPT + 99 others); Tue, 19 Sep 2023 04:28:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229772AbjISI2V (ORCPT ); Tue, 19 Sep 2023 04:28:21 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2FCD911C for ; Tue, 19 Sep 2023 01:28:15 -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 2BE031FB; Tue, 19 Sep 2023 01:28:52 -0700 (PDT) Received: from [10.57.94.129] (unknown [10.57.94.129]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B9CDE3F59C; Tue, 19 Sep 2023 01:28:13 -0700 (PDT) Message-ID: <1d513178-bab9-0522-87f5-1a058bb8121d@arm.com> Date: Tue, 19 Sep 2023 09:28:08 +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: Jean-Philippe Brucker Cc: Niklas Schnelle , Joerg Roedel , Will Deacon , 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> <20230919081519.GA3860249@myrica> From: Robin Murphy In-Reply-To: <20230919081519.GA3860249@myrica> 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 fry.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 (fry.vger.email [0.0.0.0]); Tue, 19 Sep 2023 01:28:34 -0700 (PDT) On 2023-09-19 09:15, Jean-Philippe Brucker wrote: > On Mon, Sep 18, 2023 at 05:37:47PM +0100, Robin Murphy wrote: >>> 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...) > > They're not strictly equivalent: this check works around a temporary issue > with the IOMMU core, which calls map/unmap before the domain is finalized. > Once we merge domain_alloc() and finalize(), then this check disappears, > but we still need to test nr_endpoints in map/unmap to handle detached > domains (and we still need to fix the synchronization of nr_endpoints > against attach/detach). That's why I preferred doing this on viommu and > keeping it in one place. Fair enough - it just seems to me that in both cases it's a detached domain, so its previous history of whether it's ever been otherwise or not shouldn't matter. Even once viommu is initialised, does it really make sense to send sync commands for a mapping on a detached domain where we haven't actually sent any map/unmap commands? Thanks, Robin.