From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E7DACD1CDD1 for ; Tue, 22 Oct 2024 10:15:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:To:Subject:Cc:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=weKYFtE+Grvt0txWPZ99DRdjRGzMBRruooR/2yUrI0w=; b=YgXlhhzVW1uCvo8OZDSfbp3WMn n8Ge+e/U0UINyNZf1+XkqUJQJyBE+e4sX2zxVR3r5qQRyeJrHqeOUMAw2utlUCDDd/gWT1KoXNRmL Ei0v/mTOi+f2emGVr5yUbF+sNTgWWscQ2VhL3H97lwP3SJAJH1pqgtpXc3IHM67Lvpt41Sk7OTzfe vw80UVbQYqnMkffgv6VZhIWHR5XkrmJ+GxVP/I24UGPOtPVNdUT0beUQ+Ystd6SZZdF+cBso8ExSf p966s1VwdGedmQGYSak7O94fjgcboNOuQcaNuaeo45iB0hnYNurZDCwMBgESpzAD+8uYhyG321kwP EihXS6aQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t3BvO-0000000AUnC-2NAv; Tue, 22 Oct 2024 10:15:38 +0000 Received: from mgamail.intel.com ([192.198.163.19]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t3AjY-0000000AGP5-19Pt for linux-arm-kernel@lists.infradead.org; Tue, 22 Oct 2024 08:59:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1729587560; x=1761123560; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=PAGAisR6ewXfOUos22t2tN5MyLH3MNDX5PNO1iIvpyA=; b=lUm11PT7cmVQw/2RPxqN169SVMatrfC4G3qGgRmA+OPCM0MClsDhtBS4 ECcTelH9NL3H1Oua2RyKKUEKpNa/VjQLSwK6erYrFrjIJWud3wd5TCT3C dXeAEjW+AT9c67yIW7mJbbgIJRZZHrFyxOqtdME7tAWAo/nQNgLDkzrTe czRmsDs3iuEuf9DONyeBvyLVElsOZBGQRZhreRGsDIiW2gKUPJA3mo/Pa Ie5dX0z1hLWproWzgMoKZJb+vxDj4lH5soK+jjofFo2iBlGtpxhjwpIh2 pX4UCNDmZCTm9Cux9tk7KPQqt0IouCfn+j77u43gc5EsRvy/NaEnh3GUK Q==; X-CSE-ConnectionGUID: tsUR91QdSzGErhjeGXrnmg== X-CSE-MsgGUID: g7rat/GKRHubj9Wd/tYpOw== X-IronPort-AV: E=McAfee;i="6700,10204,11232"; a="28565094" X-IronPort-AV: E=Sophos;i="6.11,222,1725346800"; d="scan'208";a="28565094" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Oct 2024 01:59:15 -0700 X-CSE-ConnectionGUID: FNRSmUgqTXuU/HdcuQ6hIA== X-CSE-MsgGUID: Sezsu89GSvK2DH0qqjq6Pw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,222,1725346800"; d="scan'208";a="110616836" Received: from blu2-mobl.ccr.corp.intel.com (HELO [10.124.240.228]) ([10.124.240.228]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Oct 2024 01:59:10 -0700 Message-ID: Date: Tue, 22 Oct 2024 16:59:07 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: baolu.lu@linux.intel.com, jgg@nvidia.com, kevin.tian@intel.com, will@kernel.org, joro@8bytes.org, suravee.suthikulpanit@amd.com, robin.murphy@arm.com, dwmw2@infradead.org, shuah@kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org, eric.auger@redhat.com, jean-philippe@linaro.org, mdf@kernel.org, mshavit@google.com, shameerali.kolothum.thodi@huawei.com, smostafa@google.com, yi.l.liu@intel.com, aik@amd.com, zhangfei.gao@linaro.org, patches@lists.linux.dev Subject: Re: [PATCH v4 02/11] iommufd: Introduce IOMMUFD_OBJ_VIOMMU and its related struct To: Nicolin Chen References: <74fec8c38a7d568bd88beba9082b4a5a4bc2046f.1729553811.git.nicolinc@nvidia.com> Content-Language: en-US From: Baolu Lu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241022_015920_365709_94EF2171 X-CRM114-Status: GOOD ( 13.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2024/10/22 12:40, Nicolin Chen wrote: > On Tue, Oct 22, 2024 at 10:28:30AM +0800, Baolu Lu wrote: >> On 2024/10/22 8:19, Nicolin Chen wrote: >>> + * @viommu_alloc: Allocate an iommufd_viommu on a physical IOMMU instance behind >>> + * the @dev, as the set of virtualization resources shared/passed >>> + * to user space IOMMU instance. And associate it with a nesting >>> + * @parent_domain. The @viommu_type must be defined in the header >>> + * include/uapi/linux/iommufd.h >>> + * It is suggested to call iommufd_viommu_alloc() helper for >>> + * a bundled allocation of the core and the driver structures, >>> + * using the given @ictx pointer. >>> * @pgsize_bitmap: bitmap of all possible supported page sizes >>> * @owner: Driver module providing these ops >>> * @identity_domain: An always available, always attachable identity >>> @@ -591,6 +601,10 @@ struct iommu_ops { >>> void (*remove_dev_pasid)(struct device *dev, ioasid_t pasid, >>> struct iommu_domain *domain); >>> >>> + struct iommufd_viommu *(*viommu_alloc)( >>> + struct device *dev, struct iommu_domain *parent_domain, >>> + struct iommufd_ctx *ictx, unsigned int viommu_type); >> Is the vIOMMU object limited to a parent domain? > Yes, for each vIOMMU (a slice of physical IOMMU per VM), one S2 > parent domain is enough. Typically, it has the mappings between > gPAs and hPAs. If its format/compatibility allows, this single > parent domain can be shared with other vIOMMUs. Is it feasible to make vIOMMU object more generic, rather than strictly tying it to nested translation? For example, a normal paging domain that translates gPAs to hPAs could also have a vIOMMU object associated with it. While we can only support vIOMMU object allocation uAPI for S2 paging domains in the context of this series, we could consider leaving the option open to associate a vIOMMU object with other normal paging domains that are not a nested parent? Thanks, baolu