Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2998922imm; Mon, 10 Sep 2018 09:25:23 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYc97HHLBFMuzUpx1W4oJo/SIF1RBEgK+eemge0f9pJRJHwZuXYbrFHIOwFsGaJUEPW5pTG X-Received: by 2002:a62:d94:: with SMTP id 20-v6mr24546644pfn.202.1536596723473; Mon, 10 Sep 2018 09:25:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536596723; cv=none; d=google.com; s=arc-20160816; b=mzgZAUq7LOVX4eNpQ/99dT5YS/LVjj4fxiDE3fWKcEStp0xitgEgaw6y9LQAYEaEc3 XwrSKDsdIF0q2u/p9TClFt6J2nz8p/ldhgZmAEiXeEr4wohC5KvrmGoOpIbn/iWIvJNw 27gnlN7UQDMDUXIRBq4Bjm+cmSNYw88JdqKDfwkdgvEXv5Y2syP7vjJLBaF6RFHNSY5d yy34ECn/AJ5VnLriaOc0t3PDJC6U5nbAZ09VD8Nb7FWdLBFFzNJOGRyhxAB8JsaCw11Q R79E1Gr1kCornKgBZPmU+AM0YWNdedPKMHos8Bj5br1bc4sH6pNafKBopkHOtzXiEQfV pchg== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=kbileh48TEneqDr0a72seRJFW9c3dzSXP6dHpu1AILs=; b=DQ3LR0zgcpALGC8VwRT/Y9jf0OLG7X4Xx7hdY7BXS/98fne/bWQeolP0qW6VUFiEYx 85u9bWiToQi0tlj8Gj6TK5nOXv/bGY8ujJmnrh0lRKv5YOzzhnwuHIF21gvDze3kRa+g awgdN5HPtosvdxhoMXz/V7U9zZv2tJ7R18mI0PYULg+WCkY7Sr6wHYoIuW5YBD92/QAM tJwW+juh6aabhsahXPn11uv4zENsFajYsnLiGZXWrgNxf/Rxf1qrVpUIY5pcxGNQSKuu 7LzB4KSfPU6tmXCDtSHRYJj3RqFsanye+a/n/Jg+9h4Qnz3nxiOhdw2fQ3p4508iM1mT 2OTQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k10-v6si17657790pfe.41.2018.09.10.09.25.06; Mon, 10 Sep 2018 09:25:23 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728484AbeIJVSV (ORCPT + 99 others); Mon, 10 Sep 2018 17:18:21 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:60404 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728101AbeIJVSV (ORCPT ); Mon, 10 Sep 2018 17:18:21 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 52FC218A; Mon, 10 Sep 2018 09:23:30 -0700 (PDT) Received: from [10.4.12.111] (ostrya.emea.arm.com [10.4.12.111]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8170F3F557; Mon, 10 Sep 2018 09:23:27 -0700 (PDT) Subject: Re: [RFC PATCH v2 08/10] vfio/type1: Add domain at(de)taching group helpers To: Lu Baolu , Joerg Roedel , David Woodhouse , Alex Williamson , Kirti Wankhede Cc: kevin.tian@intel.com, ashok.raj@intel.com, tiwei.bie@intel.com, sanjay.k.kumar@intel.com, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, yi.y.sun@intel.com, jacob.jun.pan@intel.com, kvm@vger.kernel.org References: <20180830040922.30426-1-baolu.lu@linux.intel.com> <20180830040922.30426-9-baolu.lu@linux.intel.com> From: Jean-Philippe Brucker Message-ID: Date: Mon, 10 Sep 2018 17:23:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180830040922.30426-9-baolu.lu@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/08/2018 05:09, Lu Baolu wrote: > +static int vfio_detach_aux_domain(struct device *dev, void *data) > +{ > + struct iommu_domain *domain = data; > + > + vfio_mdev_set_aux_domain(dev, NULL); > + iommu_detach_device(domain, dev->parent); I think that's only going to work for vt-d, which doesn't use a default_domain. For other drivers, iommu.c ends up calling domain->ops->attach_dev(default_domain, dev) here, which isn't what we want. That was my concern with reusing attach/detach_dev callbacks for PASID management. The attach_dev code of IOMMU drivers already has to deal with toggling between default and unmanaged domain. Dealing with more state transitions in the same path is going to be difficult. Thanks, Jean