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 E89A6C6FA99 for ; Fri, 10 Mar 2023 15:58:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: 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=u5Uo1r6Bf600kv6vaJZZ5tASti/iipuUbUc607IFLrg=; b=KdswPTsB6k3Lkh zTsNYBwjV3cnvWflHa1O7xyCq0djLzMijDE9Dsb56oWHnRR3PO+IDG6ayLE5kvfYk4AVMAR+Jzhbs fJJ81MLmuE/a5eklBMBXwgkG4MxPfr4UHX+IIEQX2XPJ/Fh4sv/8ZHTeFnU2zDEMcQTZc8dG5POAI PYjsbERRVu9G7h3ED4nQzvKR9p3AIZgmeGufWGLmeVHmXZi22oJeQO9++O6cmJ8TGKUJI+A9y+xO3 27Y05rPmgqnfYYeou7J0ZX7GaM1r8nCJFXvBHUAoIgUWZ3Wz1ZuFeA517EbYxoWv5KGjxz1eD42/e 6ctGjKDuYnk7O1wUy8RQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1paf7q-00F8xh-ME; Fri, 10 Mar 2023 15:57:47 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1paf7k-00F8vO-66 for linux-arm-kernel@lists.infradead.org; Fri, 10 Mar 2023 15:57:42 +0000 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 2FB1F4B3; Fri, 10 Mar 2023 07:58:22 -0800 (PST) Received: from [10.57.90.67] (unknown [10.57.90.67]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B72473F5A1; Fri, 10 Mar 2023 07:57:36 -0800 (PST) Message-ID: <029bb2f5-78d5-a3f2-1ae7-97fc7147611d@arm.com> Date: Fri, 10 Mar 2023 15:57:27 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v1 02/14] iommufd: Add nesting related data structures for ARM SMMUv3 Content-Language: en-GB To: Jason Gunthorpe Cc: Jean-Philippe Brucker , Nicolin Chen , will@kernel.org, eric.auger@redhat.com, kevin.tian@intel.com, baolu.lu@linux.intel.com, joro@8bytes.org, shameerali.kolothum.thodi@huawei.com, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, yi.l.liu@intel.com References: <364cfbe5b228ab178093db2de13fa3accf7a6120.1678348754.git.nicolinc@nvidia.com> <20230309134217.GA1673607@myrica> <20230309182659.GA1710571@myrica> <82f5b94b-01fe-5c99-608c-f7d124247b7c@arm.com> From: Robin Murphy In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230310_075740_375183_1EE06169 X-CRM114-Status: GOOD ( 25.20 ) 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2023-03-10 15:25, Jason Gunthorpe wrote: > On Fri, Mar 10, 2023 at 02:52:42PM +0000, Robin Murphy wrote: >> On 2023-03-09 21:01, Jason Gunthorpe wrote: >>>> For a lot of SMMUv3 implementations that have a single queue and for >>>> other architectures, we can do better than hardware emulation. >>> >>> How is using a SW emulated virtio formatted queue better than using a >>> SW emulated SMMUv3 ECMDQ? >> >> Since it's not been said, the really big thing is that virtio explicitly >> informs the host whenever the guest maps something. Emulating SMMUv3 means >> the host has to chase all the pagetable pointers in guest memory and trap >> writes such that it has visibility of invalid->valid transitions and can >> update the physical shadow pagetable correspondingly. > > Sorry, I mean in the context of future virtio-iommu that is providing > nested translation. Ah, that's probably me missing the context again. > eg why would anyone want to use virtio to provide SMMUv3 based HW > accelerated nesting? > > Jean suggested that the invalidation flow for virtio-iommu could be > faster because it is in kernel, but I'm saying that we could also make > the SMMUv3 invalidation in-kernel with the same basic technique. (and > actively wondering if we should put more focus on that) > > I understand the appeal of the virtio scheme with its current > map/unmap interface. > > I could also see some appeal of a simple virtio-iommu SVA that could > point map a CPU page table as an option. The guest already has to know > how to manage these anyhow so it is nicely general. > > If iommufd could provide a general cross-driver API to set exactly > that scenario up then VMM code could also be general. That seems > prettty interesting. Indeed, I've always assumed the niche for virtio would be that kind of in-between use-case using nesting to accelerate simple translation, where we plug a guest-owned pagetable into a host-owned context. That way the guest retains the simple virtio interface and only needs to understand a pagetable format (or as you say, simply share a CPU pagetable) without having to care about the nitty-gritty of all the IOMMU-specific moving parts around it. For guests that want to get into more advanced stuff like managing their own PASID tables, pushing them towards "native" nesting probably does make more sense. > But if the plan is to expose more detailed stuff like the CD or GCR3 > PASID tables as something the guest has to manipulate and then a bunch > of special invalidation to support that, and VMM code to back it, then > I'm questioning the whole point. We lost the generality. > > Just use the normal HW accelerated SMMUv3 nesting model instead. > > If virtio-iommu SVA is really important for ARM then I'd suggest > SMMUv3 should gain a new HW capability to allowed the CD table to be > in hypervisor memory so it works consistently for virtio-iommu SVA. Oh, maybe I should have read this far before reasoning the exact same thing from scratch... oh well, this time I'm not going to go back and edit :) Thanks, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel