Received: by 10.213.65.68 with SMTP id h4csp33819imn; Mon, 12 Mar 2018 16:27:37 -0700 (PDT) X-Google-Smtp-Source: AG47ELsUen0hsmtZxpSlp6nIBul7lQ15txL/ACxFDPdq7QynBJSbE9umhCNCQniAGR1qBu6aHJgb X-Received: by 2002:a17:902:7b95:: with SMTP id w21-v6mr10020993pll.260.1520897257703; Mon, 12 Mar 2018 16:27:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520897257; cv=none; d=google.com; s=arc-20160816; b=DArklGjymTUwkD9PRv7OANLkmkz9x1RBYpd0zBVWSxdJhNXc/v2DTbSyy+JSwm+WUp vUxBVrnj7tXBbFIjrq/sFRLKFWSn/M+Fb1jFZy2OxS3DvwL+KRvCn9qyLQaCdCx2xE4X 9voFKXbfJOXEyRDGd6s9OOzxJxL+xKFm2ZxV3Kk/ZnupB+Bn+FpSFE2/eWhqYpKOng2a kCwDdCcxm02iOM4melmNj6cq92i7C85z4XZ5r91P4NBUEwilKIL0UuMo+6vG7BJFGObI kcEQn1EBiMeoQcynM12Fx4IwUKyXMazkqZmZzkj5TKtbkO4Gz/4mOIwP3KdYh3oD0NAQ 3F7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=qbEEjHZ2NocN91QJAyCqrgi9/lRcq5QcD13ed18nZKY=; b=uiF/SfjLABsxMIZadU+/ONizhU5BKHIi22AJt7jDa2/5zLRE8KvccSdwU5ooDzyGvJ 6jjbxow52k7CDXRbjj97LPV/GoKve1hmaZqvunXYTb7Lca+uleaUHw/BCpWJagbhPXwE rseW/PaoL+PssYAog91td3qZJTF1xTqb/+F0blQ+FpX5S/S7KLBE6G9+23BFcnxCy8Wg U/vDwpB1JSf0+Wr5rXYDVagVdT25i7kNP0mzgmqeoOKlb/YZ5uFpKOUy87AARpGjJCNI NcjsOYMGi0FaQn22FrFCXkJ/9UllBqHTvYHcHZUvKTe3LCdTI4cZfrFbtMS/1ewCjE1b 8abg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f1-v6si6748825plb.73.2018.03.12.16.27.22; Mon, 12 Mar 2018 16:27:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932246AbeCLX0a (ORCPT + 99 others); Mon, 12 Mar 2018 19:26:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33772 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751312AbeCLX03 (ORCPT ); Mon, 12 Mar 2018 19:26:29 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2AA1D5F7B1; Mon, 12 Mar 2018 23:26:29 +0000 (UTC) Received: from w520.home (ovpn-117-203.phx2.redhat.com [10.3.117.203]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6E4CC17AB7; Mon, 12 Mar 2018 23:26:28 +0000 (UTC) Date: Mon, 12 Mar 2018 17:26:27 -0600 From: Alex Williamson To: Filippo Sironi Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Shameer Kolothum Subject: Re: [PATCH] vfio/type1: Search for a fitting iommu_domain before attaching the iommu_group Message-ID: <20180312172627.583351bc@w520.home> In-Reply-To: <1520269271-12662-1-git-send-email-sironi@amazon.de> References: <1520269271-12662-1-git-send-email-sironi@amazon.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 12 Mar 2018 23:26:29 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Cc +Shameer] Hi Filippo, On Mon, 5 Mar 2018 18:01:11 +0100 Filippo Sironi wrote: > ... to avoid an unnecessary attach/detach of the iommu_group to the > newly created iommu_domain. This also saves us a context-cache and an > IOTLB flush. > > This is possible because allocating an iommu_domain for the iommu_group > we're attaching is enough to understand whether a fitting iommu_domain > already exists. The history here is that testing the coherency of the domain used to be based on the domain, allowing the IOMMU driver to support multiple hardware units with potentially different features. This has since become a bus_type attribute, but see Shameer's patch series adding support for IOVA lists: https://lkml.org/lkml/2018/2/21/355 This will returns similar requirements as we previously had for coherency as attributes such as geometry are per domain and I don't see that the IOMMU API guarantees that those attributes don't change based on the attached devices/groups. In fact there's quite a bit of code pending that assumes those attributes can change based on the attached devices. So, I don't think we can do this and enhance our IOVA handling. Thanks, Alex > Signed-off-by: Filippo Sironi > Cc: Alex Williamson > Cc: kvm@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > drivers/vfio/vfio_iommu_type1.c | 32 ++++++++++++++------------------ > 1 file changed, 14 insertions(+), 18 deletions(-) > > diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c > index 45657e2b1ff7..88359b4993f3 100644 > --- a/drivers/vfio/vfio_iommu_type1.c > +++ b/drivers/vfio/vfio_iommu_type1.c > @@ -1279,15 +1279,8 @@ static int vfio_iommu_type1_attach_group(void *iommu_data, > goto out_domain; > } > > - ret = iommu_attach_group(domain->domain, iommu_group); > - if (ret) > - goto out_domain; > - > resv_msi = vfio_iommu_has_sw_msi(iommu_group, &resv_msi_base); > > - INIT_LIST_HEAD(&domain->group_list); > - list_add(&group->next, &domain->group_list); > - > msi_remap = irq_domain_check_msi_remap() || > iommu_capable(bus, IOMMU_CAP_INTR_REMAP); > > @@ -1295,7 +1288,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data, > pr_warn("%s: No interrupt remapping support. Use the module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this platform\n", > __func__); > ret = -EPERM; > - goto out_detach; > + goto out_domain; > } > > if (iommu_capable(bus, IOMMU_CAP_CACHE_COHERENCY)) > @@ -1311,21 +1304,24 @@ static int vfio_iommu_type1_attach_group(void *iommu_data, > list_for_each_entry(d, &iommu->domain_list, next) { > if (d->domain->ops == domain->domain->ops && > d->prot == domain->prot) { > - iommu_detach_group(domain->domain, iommu_group); > - if (!iommu_attach_group(d->domain, iommu_group)) { > - list_add(&group->next, &d->group_list); > - iommu_domain_free(domain->domain); > - kfree(domain); > - mutex_unlock(&iommu->lock); > - return 0; > - } > - > - ret = iommu_attach_group(domain->domain, iommu_group); > + ret = iommu_attach_group(d->domain, iommu_group); > if (ret) > goto out_domain; > + list_add(&group->next, &d->group_list); > + iommu_domain_free(domain->domain); > + kfree(domain); > + mutex_unlock(&iommu->lock); > + return 0; > } > } > > + ret = iommu_attach_group(domain->domain, iommu_group); > + if (ret) > + goto out_domain; > + > + INIT_LIST_HEAD(&domain->group_list); > + list_add(&group->next, &domain->group_list); > + > vfio_test_domain_fgsp(domain); > > /* replay mappings on new domains */