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 X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23E41C433B4 for ; Wed, 19 May 2021 23:25:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EB383610CB for ; Wed, 19 May 2021 23:25:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229556AbhESX0X (ORCPT ); Wed, 19 May 2021 19:26:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229498AbhESX0X (ORCPT ); Wed, 19 May 2021 19:26:23 -0400 Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6778C061574 for ; Wed, 19 May 2021 16:25:01 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id v8so14540428qkv.1 for ; Wed, 19 May 2021 16:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jofypBmuNK78helxp/ax3lvvaD1SSYgX9AHCXeb2JyI=; b=N+FIikMxArUHq1byG1kV6q6NKiH1yzdaJ73QnFvU7gnei0NcXatMYjDQ/ysJWeBJUz HU+0NNBklt3GiG1WqihmEZDLgrsaMez/pjd1gK+nq1yfEAl4wKARzYJcQ9YvICi1PbfJ YmKCfYOaNFRsx04nfwkEcco4XkSA5EJzUpFfr7AW5h4ojV2pmxtrP0yLMHPB89Npr6MC cYvKGOLX7tUJB9fr5WHNwIUnrPHLmMT3XH1oZkYwxMdMuAS8LI+qL0xR0NfXu2XozXzX mnVR8EYQcltbwycZy/8FNlwePUV7aMDd/SY0pRucP8XY2ZQWC41lv4cyNLN79dAK3X8D 3g1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jofypBmuNK78helxp/ax3lvvaD1SSYgX9AHCXeb2JyI=; b=ugy+5shZ2ZgaLDOAk7r/hhPhoz2G7kocooO77Wlo26vT5Ax8zvULEiQV4ax4oL0GpJ HCvb1HHqwfEXo2cj3GPPwuOOx5wdIhGJjEd5L5AAjnh8P7KjsMbQiEYxEgcYFVOHJxmH 74UoVIb2tubcsTvXt1wwIsbx7gkW7GcW1fp5hYLU9OJsddgLyaAAqIuggjDgAn0VdcBP ljlRBxwhuw91KXlIhVr6MffAHIf9iQ5+v/dkNs41cCBrpYIAm6xpzQ2eRx4VfdATKQ5X yZh/VBPhXeyUMum63rNI+2/5g8ZdCw+jkzozHBbTpFfFNL2kItVBuRDGKbPoZcFQIdwD SidA== X-Gm-Message-State: AOAM5311G2WN8KT07JkjbnT4VGT/X436oeraWPtJ4V34YNgMZSmOGQG+ m1t+/CEm5UhWIPc0WNFrtvC1Ug== X-Google-Smtp-Source: ABdhPJwacQNrdgaaDkGD5jqXNtEa9dtPcTdGRZpUC1+HOzqirLQtKg5p7syqrmkzIKN+BpViLEFW6Q== X-Received: by 2002:a05:620a:21c5:: with SMTP id h5mr1932597qka.395.1621466700858; Wed, 19 May 2021 16:25:00 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-47-55-113-94.dhcp-dynamic.fibreop.ns.bellaliant.net. [47.55.113.94]) by smtp.gmail.com with ESMTPSA id u186sm918257qkd.30.2021.05.19.16.24.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 May 2021 16:25:00 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1ljVYh-00AxO2-BM; Wed, 19 May 2021 20:24:59 -0300 Date: Wed, 19 May 2021 20:24:59 -0300 From: Jason Gunthorpe To: "Tian, Kevin" Cc: Robin Murphy , Joerg Roedel , "kvm@vger.kernel.org" , Will Deacon , Kirti Wankhede , "iommu@lists.linux-foundation.org" , Alex Williamson , David Woodhouse , Christoph Hellwig , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 3/6] vfio: remove the unused mdev iommu hook Message-ID: <20210519232459.GV1096940@ziepe.ca> References: <20210514133143.GK1096940@ziepe.ca> <20210517123010.GO1096940@ziepe.ca> <20210517133500.GP1096940@ziepe.ca> <131327e3-5066-7a88-5b3c-07013585eb01@arm.com> <20210519180635.GT1096940@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, May 19, 2021 at 11:12:46PM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe > > Sent: Thursday, May 20, 2021 2:07 AM > > > > On Wed, May 19, 2021 at 04:23:21PM +0100, Robin Murphy wrote: > > > On 2021-05-17 16:35, Joerg Roedel wrote: > > > > On Mon, May 17, 2021 at 10:35:00AM -0300, Jason Gunthorpe wrote: > > > > > Well, I'm sorry, but there is a huge other thread talking about the > > > > > IOASID design in great detail and why this is all needed. Jumping into > > > > > this thread without context and basically rejecting all the > > > > > conclusions that were reached over the last several weeks is really > > > > > not helpful - especially since your objection is not technical. > > > > > > > > > > I think you should wait for Intel to put together the /dev/ioasid uAPI > > > > > proposal and the example use cases it should address then you can give > > > > > feedback there, with proper context. > > > > > > > > Yes, I think the next step is that someone who read the whole thread > > > > writes up the conclusions and a rough /dev/ioasid API proposal, also > > > > mentioning the use-cases it addresses. Based on that we can discuss the > > > > implications this needs to have for IOMMU-API and code. > > > > > > > > From the use-cases I know the mdev concept is just fine. But if there is > > > > a more generic one we can talk about it. > > > > > > Just to add another voice here, I have some colleagues working on drivers > > > where they want to use SMMU Substream IDs for a single hardware block > > to > > > operate on multiple iommu_domains managed entirely within the > > > kernel. > > > > If it is entirely within the kernel I'm confused how mdev gets > > involved? mdev is only for vfio which is userspace. > > > > Just add some background. aux domain is used to support mdev but they > are not tied together. Literally aux domain just implies that there could be > multiple domains attached to a device then when one of them becomes > the primary all the remaining are deemed as auxiliary. From this angle it > doesn't matter whether the requirement of multiple domains come from > user or kernel. You can't entirely use aux domain from inside the kernel because you can't compose it with the DMA API unless you also attach it to some struct device, and where will the struct device come from? We already talked about this on the "how to use PASID from the kernel" thread. If Robin just wants to use a stream ID from a kernel driver then that API to make a PASID == RID seems like a better answer for kernel DMA than aux domains is. Jason