Message ID | 20231202092113.14141-1-yan.y.zhao@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp1674489vqy; Sat, 2 Dec 2023 01:50:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IHWij2c/1F1GKZS8q6zSXhzuclh0RRM82dqxTN+PligduPA2VVb5YmQvpzObRNQKZ9r/PZb X-Received: by 2002:a05:6358:cc02:b0:170:17eb:2044 with SMTP id gx2-20020a056358cc0200b0017017eb2044mr900836rwb.45.1701510619859; Sat, 02 Dec 2023 01:50:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701510619; cv=none; d=google.com; s=arc-20160816; b=mZ6pgQ4KXnWLMQNXH/2UJUHMcC+m+fgqe2WUooz0/lIy+zdqR0OaNtEgWdFBBKkHQc xDml16nr1IchsmzrUZTXnuPCVamuAw/BT12ieYmiHit9HY8QxamcjGT4e/WKaZxdruWr vueeAQL1RF7ZkHM+UDsK86HAAYKZjgliHX57PeFwhZiuGolIVLXm8GDHN7dQoWClzavB AZBvyu50hEk1yLvry6TnMtwZvWT6yu3dwrJVldaiorD5ZCA6qQWJOSNYRwWwQLhID3jS 1g4nAa2vWvFK0hFBtz/5wM5VscoRW+u84hvkxBHq6/dJTwgigaizK2QJc8pg833X3MrP gMKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from:dkim-signature; bh=8cQwr3wX3HEzTKQTQihscxpkzdptuxUve0JLqCmDxcQ=; fh=+WI4m5k3dRLR+dR3neThuZkNBTzIm/a8HgtddERL9fA=; b=OEEV8BNHSLHQp0FSm/ZGohpHrk6Ud0QNprnoQFTE36wszXhnvUlvxkPyeTtUFOtOEo H05dgkIuUWrIdcwKMtYiQ2j6UYojhbOjEUQdXu0DNBZrj5nD7RdcPVYAWct6QpD2Zzer c+o1IzzCXc9PyOmgeXZh/VNW+Ngwzh+O3IYQllsWkVf9dt8KEle9jmLvd/J740lbO3Zv jPhgjV6NZeSXI0jjz5Wnn+FzpoUpzch67sby2jU7c3id1zSa5t8gHwQcL2rpw3JbbpPp CLuIcmLuUCp3IQ/aetn/iXn8Yl6qieBWduAHwRM1lmIvbftbUulzEWkpj0a28Z9fGN0+ LK4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bynbUnr1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 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 morse.vger.email (morse.vger.email. [23.128.96.31]) by mx.google.com with ESMTPS id x21-20020a63f715000000b005bd04873387si4699075pgh.105.2023.12.02.01.50.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 01:50:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bynbUnr1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 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 (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 631028297C54; Sat, 2 Dec 2023 01:50:17 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232326AbjLBJuI (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Sat, 2 Dec 2023 04:50:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229472AbjLBJuG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 2 Dec 2023 04:50:06 -0500 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C7D34197; Sat, 2 Dec 2023 01:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1701510612; x=1733046612; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=WCJPtEQsnD+jMdSa58ByeKd9Udd++7gtpjWFBhxkT8o=; b=bynbUnr1p6FdWy3LqmAyL6aefJu7Unp06M5joR+PftSgrlnnWLwr0Pgv yo9VKa/GofQMK2WFUmylPmM/3N9/GROo4q1AVgSFQTP3HXXUBvfF9anl0 pYb3RSobbyttdC9zETXEtH4txe9EZrZlfk8OxDuO0rEmir/9txVQEXhDY oKrxNtSkSjRDisx2NAB7Se6YcxwHG14Gk41KEn2b97W4LgnUWHSJeRNuX IZccfX9H2OhqUSnX5pu4jhPVPYUei1hpw2CXmYsRuHs2ykHIEIXV7RQNQ v96KWXkGjNym3A6/gE2K9kASPv3bG61SMMVY4aeHg/q5lW1v9WNC3oB/B g==; X-IronPort-AV: E=McAfee;i="6600,9927,10911"; a="479794120" X-IronPort-AV: E=Sophos;i="6.04,245,1695711600"; d="scan'208";a="479794120" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2023 01:50:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.04,245,1695711600"; d="scan'208";a="11414203" Received: from yzhao56-desk.sh.intel.com ([10.239.159.62]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2023 01:50:09 -0800 From: Yan Zhao <yan.y.zhao@intel.com> To: iommu@lists.linux.dev, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: alex.williamson@redhat.com, jgg@nvidia.com, pbonzini@redhat.com, seanjc@google.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, kevin.tian@intel.com, baolu.lu@linux.intel.com, dwmw2@infradead.org, yi.l.liu@intel.com, Yan Zhao <yan.y.zhao@intel.com> Subject: [RFC PATCH 12/42] iommufd: Introduce allocation data info and flag for KVM managed HWPT Date: Sat, 2 Dec 2023 17:21:13 +0800 Message-Id: <20231202092113.14141-1-yan.y.zhao@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20231202091211.13376-1-yan.y.zhao@intel.com> References: <20231202091211.13376-1-yan.y.zhao@intel.com> X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Sat, 02 Dec 2023 01:50:17 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784163199881675122 X-GMAIL-MSGID: 1784163199881675122 |
Series |
Sharing KVM TDP to IOMMU
|
|
Commit Message
Yan Zhao
Dec. 2, 2023, 9:21 a.m. UTC
Add allocation data info iommu_hwpt_kvm_info to allow IOMMUFD to create a
KVM managed HWPT via ioctl IOMMU_HWPT_ALLOC.
As KVM managed HWPT serves as stage-2 page tables whose paging structure
and page mapping/unmapping are managed by KVM, there's no need to connect
KVM managed HWPT to IOAS or parent HWPT.
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
---
include/uapi/linux/iommufd.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
Comments
On Sat, Dec 02, 2023 at 05:21:13PM +0800, Yan Zhao wrote: > @@ -413,11 +422,13 @@ struct iommu_hwpt_arm_smmuv3 { > * @IOMMU_HWPT_DATA_NONE: no data > * @IOMMU_HWPT_DATA_VTD_S1: Intel VT-d stage-1 page table > * @IOMMU_HWPT_DATA_ARM_SMMUV3: ARM SMMUv3 Context Descriptor Table > + * @IOMMU_HWPT_DATA_KVM: KVM managed stage-2 page table > */ > enum iommu_hwpt_data_type { > IOMMU_HWPT_DATA_NONE, > IOMMU_HWPT_DATA_VTD_S1, > IOMMU_HWPT_DATA_ARM_SMMUV3, > + IOMMU_HWPT_DATA_KVM, > }; Definately no, the HWPT_DATA is for the *driver* - it should not be "kvm". Add the kvm fd to the main structure Jason
On Mon, Dec 04, 2023 at 02:29:28PM -0400, Jason Gunthorpe wrote: > On Sat, Dec 02, 2023 at 05:21:13PM +0800, Yan Zhao wrote: > > > @@ -413,11 +422,13 @@ struct iommu_hwpt_arm_smmuv3 { > > * @IOMMU_HWPT_DATA_NONE: no data > > * @IOMMU_HWPT_DATA_VTD_S1: Intel VT-d stage-1 page table > > * @IOMMU_HWPT_DATA_ARM_SMMUV3: ARM SMMUv3 Context Descriptor Table > > + * @IOMMU_HWPT_DATA_KVM: KVM managed stage-2 page table > > */ > > enum iommu_hwpt_data_type { > > IOMMU_HWPT_DATA_NONE, > > IOMMU_HWPT_DATA_VTD_S1, > > IOMMU_HWPT_DATA_ARM_SMMUV3, > > + IOMMU_HWPT_DATA_KVM, > > }; > > Definately no, the HWPT_DATA is for the *driver* - it should not be > "kvm". > > Add the kvm fd to the main structure > Do you mean add a "int kvm_fd" to "struct iommu_hwpt_alloc" ? struct iommu_hwpt_alloc { __u32 size; __u32 flags; __u32 dev_id; __u32 pt_id; __u32 out_hwpt_id; __u32 __reserved; __u32 data_type; __u32 data_len; __aligned_u64 data_uptr; }; Then always create the HWPT as IOMMUFD_OBJ_HWPT_KVM as long as kvm_fd > 0 ?
On Tue, Dec 05, 2023 at 03:08:03PM +0800, Yan Zhao wrote: > On Mon, Dec 04, 2023 at 02:29:28PM -0400, Jason Gunthorpe wrote: > > On Sat, Dec 02, 2023 at 05:21:13PM +0800, Yan Zhao wrote: > > > > > @@ -413,11 +422,13 @@ struct iommu_hwpt_arm_smmuv3 { > > > * @IOMMU_HWPT_DATA_NONE: no data > > > * @IOMMU_HWPT_DATA_VTD_S1: Intel VT-d stage-1 page table > > > * @IOMMU_HWPT_DATA_ARM_SMMUV3: ARM SMMUv3 Context Descriptor Table > > > + * @IOMMU_HWPT_DATA_KVM: KVM managed stage-2 page table > > > */ > > > enum iommu_hwpt_data_type { > > > IOMMU_HWPT_DATA_NONE, > > > IOMMU_HWPT_DATA_VTD_S1, > > > IOMMU_HWPT_DATA_ARM_SMMUV3, > > > + IOMMU_HWPT_DATA_KVM, > > > }; > > > > Definately no, the HWPT_DATA is for the *driver* - it should not be > > "kvm". > > > > Add the kvm fd to the main structure > > > Do you mean add a "int kvm_fd" to "struct iommu_hwpt_alloc" ? > struct iommu_hwpt_alloc { > __u32 size; > __u32 flags; > __u32 dev_id; > __u32 pt_id; > __u32 out_hwpt_id; > __u32 __reserved; > __u32 data_type; > __u32 data_len; > __aligned_u64 data_uptr; > }; > > Then always create the HWPT as IOMMUFD_OBJ_HWPT_KVM as long as kvm_fd > 0 ? Yes, but 0 is a valid FD so you need to add a flag 'kvm_fd valid' Jason
On Tue, Dec 05, 2023 at 10:53:04AM -0400, Jason Gunthorpe wrote: > On Tue, Dec 05, 2023 at 03:08:03PM +0800, Yan Zhao wrote: > > On Mon, Dec 04, 2023 at 02:29:28PM -0400, Jason Gunthorpe wrote: > > > On Sat, Dec 02, 2023 at 05:21:13PM +0800, Yan Zhao wrote: > > > > > > > @@ -413,11 +422,13 @@ struct iommu_hwpt_arm_smmuv3 { > > > > * @IOMMU_HWPT_DATA_NONE: no data > > > > * @IOMMU_HWPT_DATA_VTD_S1: Intel VT-d stage-1 page table > > > > * @IOMMU_HWPT_DATA_ARM_SMMUV3: ARM SMMUv3 Context Descriptor Table > > > > + * @IOMMU_HWPT_DATA_KVM: KVM managed stage-2 page table > > > > */ > > > > enum iommu_hwpt_data_type { > > > > IOMMU_HWPT_DATA_NONE, > > > > IOMMU_HWPT_DATA_VTD_S1, > > > > IOMMU_HWPT_DATA_ARM_SMMUV3, > > > > + IOMMU_HWPT_DATA_KVM, > > > > }; > > > > > > Definately no, the HWPT_DATA is for the *driver* - it should not be > > > "kvm". > > > > > > Add the kvm fd to the main structure > > > > > Do you mean add a "int kvm_fd" to "struct iommu_hwpt_alloc" ? > > struct iommu_hwpt_alloc { > > __u32 size; > > __u32 flags; > > __u32 dev_id; > > __u32 pt_id; > > __u32 out_hwpt_id; > > __u32 __reserved; > > __u32 data_type; > > __u32 data_len; > > __aligned_u64 data_uptr; > > }; > > > > Then always create the HWPT as IOMMUFD_OBJ_HWPT_KVM as long as kvm_fd > 0 ? > > Yes, but 0 is a valid FD so you need to add a flag 'kvm_fd valid' Got it, thanks!
diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h index 71c009cc614a4..08570f3a751fc 100644 --- a/include/uapi/linux/iommufd.h +++ b/include/uapi/linux/iommufd.h @@ -390,6 +390,15 @@ struct iommu_hwpt_vtd_s1 { __u32 __reserved; }; +/** + * struct iommu_hwpt_kvm_info - KVM managed stage-2 page table info + * (IOMMU_HWPT_DATA_KVM) + * @fd: The fd of the page table shared from KVM + */ +struct iommu_hwpt_kvm_info { + __aligned_u64 fd; +}; + /** * struct iommu_hwpt_arm_smmuv3 - ARM SMMUv3 Context Descriptor Table info * (IOMMU_HWPT_DATA_ARM_SMMUV3) @@ -413,11 +422,13 @@ struct iommu_hwpt_arm_smmuv3 { * @IOMMU_HWPT_DATA_NONE: no data * @IOMMU_HWPT_DATA_VTD_S1: Intel VT-d stage-1 page table * @IOMMU_HWPT_DATA_ARM_SMMUV3: ARM SMMUv3 Context Descriptor Table + * @IOMMU_HWPT_DATA_KVM: KVM managed stage-2 page table */ enum iommu_hwpt_data_type { IOMMU_HWPT_DATA_NONE, IOMMU_HWPT_DATA_VTD_S1, IOMMU_HWPT_DATA_ARM_SMMUV3, + IOMMU_HWPT_DATA_KVM, }; /** @@ -447,6 +458,10 @@ enum iommu_hwpt_data_type { * must be set to a pre-defined type corresponding to an I/O page table * type supported by the underlying IOMMU hardware. * + * A KVM-managed HWPT will be created if @data_type is IOMMU_HWPT_DATA_KVM. + * @pt_id is not queried if data_type is IOMMU_HWPT_DATA_KVM because KVM-managed + * HWPT doesn't have any IOAS or parent HWPT associated. + * * If the @data_type is set to IOMMU_HWPT_DATA_NONE, @data_len and * @data_uptr should be zero. Otherwise, both @data_len and @data_uptr * must be given.