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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 88A86C433ED for ; Mon, 17 May 2021 12:53:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 648716100C for ; Mon, 17 May 2021 12:53:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233280AbhEQMyr (ORCPT ); Mon, 17 May 2021 08:54:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230527AbhEQMyh (ORCPT ); Mon, 17 May 2021 08:54:37 -0400 Received: from theia.8bytes.org (8bytes.org [IPv6:2a01:238:4383:600:38bc:a715:4b6d:a889]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33A40C061573 for ; Mon, 17 May 2021 05:53:21 -0700 (PDT) Received: by theia.8bytes.org (Postfix, from userid 1000) id 771D72E7; Mon, 17 May 2021 14:53:18 +0200 (CEST) Date: Mon, 17 May 2021 14:53:16 +0200 From: Joerg Roedel To: Jason Gunthorpe Cc: "Tian, Kevin" , Christoph Hellwig , Alex Williamson , David Woodhouse , Lu Baolu , Will Deacon , Kirti Wankhede , "linux-arm-kernel@lists.infradead.org" , "iommu@lists.linux-foundation.org" , "kvm@vger.kernel.org" Subject: Re: [PATCH 3/6] vfio: remove the unused mdev iommu hook Message-ID: References: <20210510065405.2334771-4-hch@lst.de> <20210510155454.GA1096940@ziepe.ca> <20210513120058.GG1096940@ziepe.ca> <20210514121925.GI1096940@ziepe.ca> <20210514133143.GK1096940@ziepe.ca> <20210517123010.GO1096940@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210517123010.GO1096940@ziepe.ca> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, May 17, 2021 at 09:30:10AM -0300, Jason Gunthorpe wrote: > On Mon, May 17, 2021 at 02:22:06PM +0200, Joerg Roedel wrote: > > Yes, I know, We have the AUX-domain specific functions now, but I > > suggested a while back to turn the mdev code into its own bus > > implementation and let the IOMMU driver deal with whether it has an mdev > > or a pdev. When that is done the aux-specific functions can go away. > > Yuk, no. > > PASID is not connected to the driver model. It is inherently wrong to > suggest this. There will be no drivers for that, but an mdev is a container for resources of a physical device which can be assigned to a virtual machine or a user-space process. In this way it fits very well into the existing abstractions. > PASID is a property of a PCI device and any PCI device driver should > be able to spawn PASIDs without silly restrictions. Some points here: 1) The concept of PASIDs is not limited to PCI devices. 2) An mdev is not a restriction. It is an abstraction with which other parts of the kernel can work. > Fixing the IOMMU API is clearly needed here to get a clean PASID > implementation in the kernel. You still have to convince me that this is needed and a good idea. By now I am not even remotely convinced and putting words like 'fixing', 'clearly' and 'silly' in a sentence is by far not enough for this to happen. > We aren't talking about mm_struct. Passing an mm_struct to a device is another use-case for PASIDs, you should keep that in mind. The mdev abstraction was made for a different use-case. To be clear, I agree that the aux-domain specifics should be removed from the IOMMU-API, but the mdev-abstraction itself still makes sense. > As above a domain isn't an IOASID, it only does a few things an IOASID > can do. For example? Regards, Joerg 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=-3.8 required=3.0 tests=BAYES_00, 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 32E77C433B4 for ; Mon, 17 May 2021 12:53:33 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B870A61166 for ; Mon, 17 May 2021 12:53:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B870A61166 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=8bytes.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 7EB3E83C82; Mon, 17 May 2021 12:53:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_XSKkYeaP2w; Mon, 17 May 2021 12:53:28 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTP id 58A7E83C4E; Mon, 17 May 2021 12:53:28 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 355AFC000D; Mon, 17 May 2021 12:53:28 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id F16CAC0001 for ; Mon, 17 May 2021 12:53:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id E010C83C4E for ; Mon, 17 May 2021 12:53:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55XGlqDu_YKz for ; Mon, 17 May 2021 12:53:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from theia.8bytes.org (8bytes.org [81.169.241.247]) by smtp1.osuosl.org (Postfix) with ESMTPS id 0644583C61 for ; Mon, 17 May 2021 12:53:20 +0000 (UTC) Received: by theia.8bytes.org (Postfix, from userid 1000) id 771D72E7; Mon, 17 May 2021 14:53:18 +0200 (CEST) Date: Mon, 17 May 2021 14:53:16 +0200 From: Joerg Roedel To: Jason Gunthorpe Subject: Re: [PATCH 3/6] vfio: remove the unused mdev iommu hook Message-ID: References: <20210510065405.2334771-4-hch@lst.de> <20210510155454.GA1096940@ziepe.ca> <20210513120058.GG1096940@ziepe.ca> <20210514121925.GI1096940@ziepe.ca> <20210514133143.GK1096940@ziepe.ca> <20210517123010.GO1096940@ziepe.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210517123010.GO1096940@ziepe.ca> Cc: "Tian, Kevin" , "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" X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Mon, May 17, 2021 at 09:30:10AM -0300, Jason Gunthorpe wrote: > On Mon, May 17, 2021 at 02:22:06PM +0200, Joerg Roedel wrote: > > Yes, I know, We have the AUX-domain specific functions now, but I > > suggested a while back to turn the mdev code into its own bus > > implementation and let the IOMMU driver deal with whether it has an mdev > > or a pdev. When that is done the aux-specific functions can go away. > > Yuk, no. > > PASID is not connected to the driver model. It is inherently wrong to > suggest this. There will be no drivers for that, but an mdev is a container for resources of a physical device which can be assigned to a virtual machine or a user-space process. In this way it fits very well into the existing abstractions. > PASID is a property of a PCI device and any PCI device driver should > be able to spawn PASIDs without silly restrictions. Some points here: 1) The concept of PASIDs is not limited to PCI devices. 2) An mdev is not a restriction. It is an abstraction with which other parts of the kernel can work. > Fixing the IOMMU API is clearly needed here to get a clean PASID > implementation in the kernel. You still have to convince me that this is needed and a good idea. By now I am not even remotely convinced and putting words like 'fixing', 'clearly' and 'silly' in a sentence is by far not enough for this to happen. > We aren't talking about mm_struct. Passing an mm_struct to a device is another use-case for PASIDs, you should keep that in mind. The mdev abstraction was made for a different use-case. To be clear, I agree that the aux-domain specifics should be removed from the IOMMU-API, but the mdev-abstraction itself still makes sense. > As above a domain isn't an IOASID, it only does a few things an IOASID > can do. For example? Regards, Joerg _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 5F34AC433B4 for ; Mon, 17 May 2021 12:57:44 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1F65E6117A for ; Mon, 17 May 2021 12:57:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1F65E6117A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=8bytes.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/NNfy4DH8tg/rWMuGL1SlYUSe6ZABqzOZRbYPUhM6mU=; b=cKbSO02SjlElktzXeBsSh9rm1 bjWIlWdfpAyuW1IlA16jVdQhUTvC7XSSMAG4mhVgmfxn71kGdBBaJS8xViWos27O0LSBpeEvR3hKS TGVT7rJ7VoyPo/ySP/prVtiUat+xYhiLZ4GuVbeho95AY1yf4iin1LgsghT19I1h3l5R+9E9a3+H3 098GqFcIY26YLaYn+cyE7HmtT6tJ5CELw2T0+8y8uVuNQH/bICnOWwXutT6oI9KE7CITMDp5+pP7f NqnEQ0MZ0NqWxAv8teUNU1GnzEviVChQs9TJhlpDWEEfQ3+PFP9WOk4FlbwJymyhCvS9ArTSR/R24 6F+G2xyWg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1licka-00Eypa-SI; Mon, 17 May 2021 12:53:37 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lickP-00EynJ-V7 for linux-arm-kernel@desiato.infradead.org; Mon, 17 May 2021 12:53:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=IQWKqnQRLfzPWIJINYSvJLVoJu0ClshLp+rngILgb0k=; b=i60loafcP8c8YaS2K2Tv899z6Y d/IjnVeAUPjfv83jl3wmYtVK1ffo+lye7q9WlU0hFgPXizsOZ18NFZWi6lWHKctQ0jVFftk8pSVji FZsCsmwFm3DAIkbX4b6PQctEIcmUDKUYNc5CjJvs0651dSuaa4pnwPEhC2o39YFxajK6tm1RVF/a8 Tg6kU4L0YmAmR8iMevl3otSohDjBDcsSIh0yDoxcuKQitTegUiAj0h5RIdJcJJyjZV5c3krgNRC/I wlQ2uaNIUYeaEzlhIMlBtpYkqa4TLzM7hSSk0BAzQ6fdToT8lhfRI0Un947VqTSDlVbWJwHU3Jyv3 F7VcudoA==; Received: from 8bytes.org ([81.169.241.247] helo=theia.8bytes.org) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lickL-00Dm2N-SR for linux-arm-kernel@lists.infradead.org; Mon, 17 May 2021 12:53:24 +0000 Received: by theia.8bytes.org (Postfix, from userid 1000) id 771D72E7; Mon, 17 May 2021 14:53:18 +0200 (CEST) Date: Mon, 17 May 2021 14:53:16 +0200 From: Joerg Roedel To: Jason Gunthorpe Cc: "Tian, Kevin" , Christoph Hellwig , Alex Williamson , David Woodhouse , Lu Baolu , Will Deacon , Kirti Wankhede , "linux-arm-kernel@lists.infradead.org" , "iommu@lists.linux-foundation.org" , "kvm@vger.kernel.org" Subject: Re: [PATCH 3/6] vfio: remove the unused mdev iommu hook Message-ID: References: <20210510065405.2334771-4-hch@lst.de> <20210510155454.GA1096940@ziepe.ca> <20210513120058.GG1096940@ziepe.ca> <20210514121925.GI1096940@ziepe.ca> <20210514133143.GK1096940@ziepe.ca> <20210517123010.GO1096940@ziepe.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210517123010.GO1096940@ziepe.ca> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210517_055322_098026_5220A873 X-CRM114-Status: GOOD ( 21.87 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, May 17, 2021 at 09:30:10AM -0300, Jason Gunthorpe wrote: > On Mon, May 17, 2021 at 02:22:06PM +0200, Joerg Roedel wrote: > > Yes, I know, We have the AUX-domain specific functions now, but I > > suggested a while back to turn the mdev code into its own bus > > implementation and let the IOMMU driver deal with whether it has an mdev > > or a pdev. When that is done the aux-specific functions can go away. > > Yuk, no. > > PASID is not connected to the driver model. It is inherently wrong to > suggest this. There will be no drivers for that, but an mdev is a container for resources of a physical device which can be assigned to a virtual machine or a user-space process. In this way it fits very well into the existing abstractions. > PASID is a property of a PCI device and any PCI device driver should > be able to spawn PASIDs without silly restrictions. Some points here: 1) The concept of PASIDs is not limited to PCI devices. 2) An mdev is not a restriction. It is an abstraction with which other parts of the kernel can work. > Fixing the IOMMU API is clearly needed here to get a clean PASID > implementation in the kernel. You still have to convince me that this is needed and a good idea. By now I am not even remotely convinced and putting words like 'fixing', 'clearly' and 'silly' in a sentence is by far not enough for this to happen. > We aren't talking about mm_struct. Passing an mm_struct to a device is another use-case for PASIDs, you should keep that in mind. The mdev abstraction was made for a different use-case. To be clear, I agree that the aux-domain specifics should be removed from the IOMMU-API, but the mdev-abstraction itself still makes sense. > As above a domain isn't an IOASID, it only does a few things an IOASID > can do. For example? Regards, Joerg _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel