Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3508490pxb; Mon, 24 Jan 2022 11:02:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJxIdySClT8Dzn90KPnPcVbhBOopJcQEzl56OrjGrs2KiR7vvsuNbD0EXrgV/iipoy2Hp9y5 X-Received: by 2002:a17:902:aa8f:b0:14a:ccfd:ca42 with SMTP id d15-20020a170902aa8f00b0014accfdca42mr15453072plr.52.1643050946399; Mon, 24 Jan 2022 11:02:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643050946; cv=none; d=google.com; s=arc-20160816; b=U36mA/XAslZZdBCoaD9pD44sJJAcnZx7Vm/fLxhjEI6sc8BAmCm4FYcH8Czp1Td0NS gVSESYTKmWsgmLExTrJ47RnGkBYUV64RBPKMFzxPUR6NHSlaKZnmZmR8/r0lkvuHp9B9 oJCFE9OVW4AjWp4H4DOSlFPwQQ5b7epw9RdciIW+8EAf0nVBWw+/TQ/ov0d4qNyznyX4 Pd9vr7s+fDTfMuGTglVX2v1+p5UQpxULXzAdWkzBHRZ/CEPj+k8h0X57vMzV/CsfvBIN me9kxNyh3hJgj7y6/Wm3BgqgwaXygF/MuppyMHpDQtf+F9uzLs/AOaYF5yom5RR9Blrf qDsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ojZJfUHtm9ovOFBOfA3TS4i8XJuJzbk79ufS2uBVn1k=; b=VLUWFtsyNmSTrg30X6LtR49pkp8mVsuLSM0PplFK41Vh/BlT4uBrWw9cQrnC3wH4yD FX41Foexy3xAMvSTALH1mCiqqSacEZewaiyqHEgCeAnesUgU8JIneVddnCLx05PHLaEJ it/zFL4e1P6MtYP6pm3c4pjFrZ0Cr5IZFRcbhZZtH/h2EB5nqA7MU47+dxzt+eVQSAHS WKOT0KVGIs8ftVUMvpbOv25qG3OKV6RoXVs9kPkxUtka+wyGfFg6asKRRaEFuQHaQIjD wf/eJ1UDCzBTRs/fDAgrFA2GCEKznHUYHGSjielmZMyEoP1ifKGkPl+EcVCoabFFSsYH AqfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=avLmskQe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l12si14343982pgr.187.2022.01.24.11.02.12; Mon, 24 Jan 2022 11:02:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=avLmskQe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236989AbiAXKQd (ORCPT + 99 others); Mon, 24 Jan 2022 05:16:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235448AbiAXKQb (ORCPT ); Mon, 24 Jan 2022 05:16:31 -0500 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 144DFC06173B for ; Mon, 24 Jan 2022 02:16:31 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id i67so1577849wma.0 for ; Mon, 24 Jan 2022 02:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ojZJfUHtm9ovOFBOfA3TS4i8XJuJzbk79ufS2uBVn1k=; b=avLmskQetnZLKS5POUDQ2emSgSxJP5gcaKobddCdXaX5XQR+TWhvS/hzwwNKCwC8rn oFFjf9l4z1YaETQpoK/vV9EvVjFQzb257aXYGPS7bVURv2toU4x9sZHaqJvfNC16FVuL Xo9e/lqUTA7XhuPdWxVSqljH4zcKUV3HGD6OGX18wzRBdWbMeI5KwKsSFPcqt6WM5tfC ti8vt1E9MNPepWL0kyFg2l9zFBDatbyVdYsMScFR9iM/NUBttzZ4tlaPVtvXkGIoG+IT wbXClwtS/a5uZ+Aq0lzabLrQdz2BPA+nSjem+g9wZZBfnDsLB8447OhCSx9OLu+8pIfP +euA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ojZJfUHtm9ovOFBOfA3TS4i8XJuJzbk79ufS2uBVn1k=; b=RXqGXZuVJ9N1tp7uxxOjeE1akaadFuBBVyrZB3u4vFFq9HxWga8QJ3Xk5eTcXluLQl QBPZwshP1PMoamjHWFTooK7WgkiW1781F38rt9jp91DGS9m5M0YWsJoPuntlMH95Ia6O GsMGR4K8QzBjjdADpYrzW0ijmlTZQLPXzGQs6tSPptWzheD1bvnw4T4YDG+ajcP+fLa2 Az4RPEJotzutzOY/Xhp6x6NY3EapqHbfi8xKRE9AI9QMpywa7IoCqZoEzJUDfkrqYPQy g0+nVowdazjFs/zoQMvxWN2vg8YG7r5PpMF/bbrO0lsUl11wEWnl9X8p9EeJJiCjf8yu 4Dbw== X-Gm-Message-State: AOAM532+tBTLQzcXB5eqBcWh2LhE5bBgHVVDhnvzrzxohWtg/o3NVShI JFYMJ6zExEBbxxohLM3loqLU1Q== X-Received: by 2002:a1c:7312:: with SMTP id d18mr1171835wmb.130.1643019389594; Mon, 24 Jan 2022 02:16:29 -0800 (PST) Received: from myrica (cpc92880-cmbg19-2-0-cust679.5-4.cable.virginm.net. [82.27.106.168]) by smtp.gmail.com with ESMTPSA id r7sm17548515wma.39.2022.01.24.02.16.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jan 2022 02:16:29 -0800 (PST) Date: Mon, 24 Jan 2022 10:16:07 +0000 From: Jean-Philippe Brucker To: "Tian, Kevin" Cc: Lu Baolu , Joerg Roedel , Jason Gunthorpe , Christoph Hellwig , Ben Skeggs , "Raj, Ashok" , Will Deacon , Robin Murphy , David Airlie , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , Jonathan Hunter , Alex Williamson , Thierry Reding , "Pan, Jacob jun" , Daniel Vetter Subject: Re: [PATCH 7/7] iommu: Add iommu_domain::domain_ops Message-ID: References: <20220124071103.2097118-1-baolu.lu@linux.intel.com> <20220124071103.2097118-8-baolu.lu@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 24, 2022 at 09:58:18AM +0000, Tian, Kevin wrote: > > From: Lu Baolu > > Sent: Monday, January 24, 2022 3:11 PM > > +/** > > + * struct domain_ops - per-domain ops > > + * @attach_dev: attach an iommu domain to a device > > + * @detach_dev: detach an iommu domain from a device > > What is the criteria about whether an op should be iommu_ops or domain_ops > when it requires both domain and device pointers like above two (and future > PASID-based attach)? > > Other examples include: > @apply_resv_region > @is_attach_deferred Could attach_dev() be an IOMMU op? So a driver could set the domain ops in attach_dev() rather than domain_alloc(). That would allow to install map()/unmap() ops that are tailored for the device's IOMMU, which we don't know at domain_alloc() time. I'm thinking about a guest that has both physical and virtual endpoints, which would ideally use different kinds of domain ops to support both efficiently (caching mode vs page tables) Thanks, Jean