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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8553C3DA78 for ; Tue, 17 Jan 2023 12:52:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236962AbjAQMwT (ORCPT ); Tue, 17 Jan 2023 07:52:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236959AbjAQMvt (ORCPT ); Tue, 17 Jan 2023 07:51:49 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 048B738EB2 for ; Tue, 17 Jan 2023 04:51:12 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F0875C14; Tue, 17 Jan 2023 04:51:53 -0800 (PST) Received: from [10.57.75.222] (unknown [10.57.75.222]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8D9763F67D; Tue, 17 Jan 2023 04:51:10 -0800 (PST) Message-ID: Date: Tue, 17 Jan 2023 12:51:03 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH 3/4] iommu: Introduce IOMMU call-back for processing struct KVM assigned to VFIO Content-Language: en-GB To: "Suthikulpanit, Suravee" , linux-kernel@vger.kernel.org, iommu@lists.linux.dev Cc: joro@8bytes.org, ashish.kalra@amd.com, thomas.lendacky@amd.com, vasant.hegde@amd.com, jon.grimm@amd.com References: <20230110143137.54517-1-suravee.suthikulpanit@amd.com> <20230110143137.54517-4-suravee.suthikulpanit@amd.com> <04dc1bc9-05ed-f6ed-f01f-7d28600fc0ce@amd.com> From: Robin Murphy In-Reply-To: <04dc1bc9-05ed-f6ed-f01f-7d28600fc0ce@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023-01-17 04:20, Suthikulpanit, Suravee wrote: > Hi Robin, > > On 1/10/2023 10:11 PM, Robin Murphy wrote: >> On 2023-01-10 14:31, Suravee Suthikulpanit wrote: >>> Currently, VFIO provide an kvm_vfio_file_set_kvm() interface for >>> assigning >>> a KVM structure to a VFIO group. The information in struct KVM is also >>> useful for IOMMU drivers when setting up VFIO domain. >>> >>> Introduce struct iommu_domain_ops.set_kvm call-back function to allow >>> IOMMU drivers to provide call-back to process the struct KVM assigned. >> >> Hmm, it sounds like this has quite some overlap of intent with the >> existing "enable_nesting" op, and my gut feeling is that it's not >> great to have two completely different "this is a VFIO domain" >> mechanisms... :/ >> >> Robin. > > Actually, the intention is to communicate KVM information, which is > already available to the VFIO down to the AMD IOMMU driver layer. I am > not sure if the enable_nesting() has enough information or the same > intention since that only communicates VFIO domain information. Sure, but from the high level view, we have on the one hand an API for "I want to use this domain in a VM (with nested paging)" and on other an API for "I want to use nested paging in this domain (for a VM)", so clearly it would be most sensible to converge on a single API for what is ultimately one single overarching use-case. I'm not claiming that the existing enable_nesting op is anywhere near the right design either; in fact I'm pretty sure it isn't, if the Arm SMMU drivers ever want to contemplate sharing stage 2 pagetables with KVM also. Cheers, Robin.