Message ID | 20230209043153.14964-2-yi.l.liu@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp122630wrn; Wed, 8 Feb 2023 20:34:57 -0800 (PST) X-Google-Smtp-Source: AK7set9fpjoKMfJJLUuBSbJgpHKyjqLljtqHxbA7HPCgnIdBwCvdoHy4DlmZ3TRbyuETE+ORKJLR X-Received: by 2002:a17:90b:4a0f:b0:230:d387:8bbb with SMTP id kk15-20020a17090b4a0f00b00230d3878bbbmr12005120pjb.5.1675917297277; Wed, 08 Feb 2023 20:34:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675917297; cv=none; d=google.com; s=arc-20160816; b=O38AxF4jFFHMu7ck/aDUbwGqceziswC0PE0yaxHUdeTOiK8wvdwylecRumVExK2xa3 sHmldLV17l/A0Eu5k7K3B3ZVczvygc5Qc1UiSiGgEVa4kVgZkEC6ktTbiGbFa+oqO/6C GS8vKIBdBHrnUY2bqWDAWBYa6TTSEwv/s88vRn+aUM+pH5XIFtAAzBORHyyms0OIWrta 9zqrf2iFg4hsfuTvZyXYFjmvEj/wJq3WJGuUFSl+oTWIgvNKXthl4saV9ExpdpOApv4I Nkofbwf3bp74vmvRgpt/b52eMz8lLIFp8phCWcjrfUJiumrGTOb99KNUnIlsxl3WVzgz 3VzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=/erSNvgFLCG3FHg6sA7QrQBhPusbyJqF540xbNlrW70=; b=UtSkziwY7Ugg6xTt9OeSlGQcs+/Khjudo/6PA5tcsruBpwwwOOaAa3ntXfRsj/fMQf XYO3JomFGkkG4vN0Ql7xS1HtkDO6jxifYMPtg1XkF7LfoSDMw+jqSpzfnj4RdSnXTaQs nEAb2+0smhDhaP2uGC863i2nCYbGDd7TNC/ZeM/mTcc16fH2wtBFitk+y0P7vkYfVZV9 qf3P1BZRi+KJRxYeF5KJgPJkMAfLXozuX9/GwRqv+eSRtZNqNVEUrT1vFk54HYZZqxP3 ULVhKpaoCM9wbkKN9HaAythf871ukMeEQ8fN9dWCza1WkGfGjL5K+vW7oh+KFjBG11zK Xn8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jcvCWnQq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z24-20020a63b918000000b004d23c2c5f75si904154pge.90.2023.02.08.20.34.36; Wed, 08 Feb 2023 20:34:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jcvCWnQq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230189AbjBIEeB (ORCPT <rfc822;gnulinuxfreebsd@gmail.com> + 99 others); Wed, 8 Feb 2023 23:34:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229777AbjBIEdk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 8 Feb 2023 23:33:40 -0500 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B584402E6; Wed, 8 Feb 2023 20:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675917152; x=1707453152; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=k19+8t5+6EA5QNZSZAcLeFZS3iJLVeK/ORk8AVxHZ2o=; b=jcvCWnQqKNCYD2pfpfofVnqpWQEwxduNqQfjyFrVR1ocNUlcXE4JTwue zqNA7Wm0k6/vccf3CnevXtNfEL6XBk//yC6txqnQU7PVg8vPCvlYq5T3d XoVwYWklJvDKTpm+7lvLy1ciH4EL2TIHzkLc+2J8uDarcI2qquIX4l80C kPWyJ+k1JMAoJyz4pZDgHAyedAHtzoeJtQx7yk5i63zTPcpV9TseP3cMf zvl+ZnHtqpNLEAU0lRPRdeB+I5Rcm3umL3fpqczPWnB76zmp690/up7Ym W5oAd1OHPmwopH16tS+oBPXX8xpLSZnbhdR/WwA1oUYM2eiaWnfNw+Oti Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10615"; a="331298592" X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="331298592" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2023 20:31:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10615"; a="669447438" X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="669447438" Received: from 984fee00a4c6.jf.intel.com ([10.165.58.231]) by fmsmga007.fm.intel.com with ESMTP; 08 Feb 2023 20:31:58 -0800 From: Yi Liu <yi.l.liu@intel.com> To: joro@8bytes.org, alex.williamson@redhat.com, jgg@nvidia.com, kevin.tian@intel.com, robin.murphy@arm.com Cc: cohuck@redhat.com, eric.auger@redhat.com, nicolinc@nvidia.com, kvm@vger.kernel.org, mjrosato@linux.ibm.com, chao.p.peng@linux.intel.com, yi.l.liu@intel.com, yi.y.sun@linux.intel.com, peterx@redhat.com, jasowang@redhat.com, shameerali.kolothum.thodi@huawei.com, lulu@redhat.com, suravee.suthikulpanit@amd.com, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, baolu.lu@linux.intel.com Subject: [PATCH 01/17] iommu: Add new iommu op to create domains owned by userspace Date: Wed, 8 Feb 2023 20:31:37 -0800 Message-Id: <20230209043153.14964-2-yi.l.liu@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230209043153.14964-1-yi.l.liu@intel.com> References: <20230209043153.14964-1-yi.l.liu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757326655992840505?= X-GMAIL-MSGID: =?utf-8?q?1757326655992840505?= |
Series |
Add Intel VT-d nested translation
|
|
Commit Message
Yi Liu
Feb. 9, 2023, 4:31 a.m. UTC
From: Lu Baolu <baolu.lu@linux.intel.com> Introduce a new iommu_domain op to create domains owned by userspace, e.g. through iommufd. These domains have a few different properties compares to kernel owned domains: - They may be MANAGED domains, but created with special parameters. For instance aperture size changes/number of levels, different IOPTE formats, or other things necessary to make a vIOMMU work - We have to track all the memory allocations with GFP_KERNEL_ACCOUNT to make the cgroup sandbox stronger - Device-specialty domains, such as NESTED domains can be created by iommufd. The new op clearly says the domain is being created by IOMMUFD, that the domain is intended for userspace use, and it provides a way to pass a driver specific uAPI structure to customize the created domain to exactly what the vIOMMU userspace driver requires. iommu drivers that cannot support VFIO/IOMMUFD should not support this op. This includes any driver that cannot provide a fully functional UNMANAGED domain. This op chooses to make the special parameters opaque to the core. This suits the current usage model where accessing any of the IOMMU device special parameters does require a userspace driver that matches the kernel driver. If a need for common parameters, implemented similarly by several drivers, arises then there is room in the design to grow a generic parameter set as well. This new op for now is only supposed to be used by iommufd, hence no wrapper for it. iommufd would call the callback directly. As for domain free, iommufd would use iommu_domain_free(). Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Yi Liu <yi.l.liu@intel.com> --- include/linux/iommu.h | 4 ++++ 1 file changed, 4 insertions(+)
Comments
> From: Liu, Yi L <yi.l.liu@intel.com> > Sent: Thursday, February 9, 2023 12:32 PM > > From: Lu Baolu <baolu.lu@linux.intel.com> > > Introduce a new iommu_domain op to create domains owned by userspace, > e.g. through iommufd. These domains have a few different properties > compares to kernel owned domains: > > - They may be MANAGED domains, but created with special parameters. > For instance aperture size changes/number of levels, different > IOPTE formats, or other things necessary to make a vIOMMU work > what is *MANAGED* domain? today we only have the separation between DMA domain and UNMANAGED domain. soon with Jason's cleanup all domains are called UNMANAGED.
On 2023/2/10 16:24, Tian, Kevin wrote: >> From: Liu, Yi L <yi.l.liu@intel.com> >> Sent: Thursday, February 9, 2023 12:32 PM >> >> From: Lu Baolu <baolu.lu@linux.intel.com> >> >> Introduce a new iommu_domain op to create domains owned by userspace, >> e.g. through iommufd. These domains have a few different properties >> compares to kernel owned domains: >> >> - They may be MANAGED domains, but created with special parameters. >> For instance aperture size changes/number of levels, different >> IOPTE formats, or other things necessary to make a vIOMMU work >> > > what is *MANAGED* domain? > > today we only have the separation between DMA domain and > UNMANAGED domain. > > soon with Jason's cleanup all domains are called UNMANAGED. It should be UNMANAGED domain. Best regards, baolu
diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 97b398d19fd2..214e3eb9bc86 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -230,6 +230,7 @@ struct iommu_iotlb_gather { * after use. Return the data buffer if success, or ERR_PTR on * failure. * @domain_alloc: allocate iommu domain + * @domain_alloc_user: allocate user iommu domain * @probe_device: Add device to iommu driver handling * @release_device: Remove device from iommu driver handling * @probe_finalize: Do final setup work after the device is added to an IOMMU @@ -262,6 +263,9 @@ struct iommu_ops { /* Domain allocation and freeing by the iommu driver */ struct iommu_domain *(*domain_alloc)(unsigned iommu_domain_type); + struct iommu_domain *(*domain_alloc_user)(struct device *dev, + struct iommu_domain *parent, + const void *user_data); struct iommu_device *(*probe_device)(struct device *dev); void (*release_device)(struct device *dev);