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 061A6C48BCF for ; Wed, 9 Jun 2021 13:32:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E1ABB6108D for ; Wed, 9 Jun 2021 13:32:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234967AbhFINef (ORCPT ); Wed, 9 Jun 2021 09:34:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54154 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231576AbhFINec (ORCPT ); Wed, 9 Jun 2021 09:34:32 -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 99F2BC06175F; Wed, 9 Jun 2021 06:32:37 -0700 (PDT) Received: by theia.8bytes.org (Postfix, from userid 1000) id 7774036A; Wed, 9 Jun 2021 15:32:35 +0200 (CEST) Date: Wed, 9 Jun 2021 15:32:34 +0200 From: Joerg Roedel To: Jason Gunthorpe Cc: "Tian, Kevin" , "Alex Williamson (alex.williamson@redhat.com)" , Jean-Philippe Brucker , David Gibson , Jason Wang , "parav@mellanox.com" , "Enrico Weigelt, metux IT consult" , Paolo Bonzini , Shenming Lu , Eric Auger , Jonathan Corbet , "Raj, Ashok" , "Liu, Yi L" , "Wu, Hao" , "Jiang, Dave" , Jacob Pan , Kirti Wankhede , Robin Murphy , "kvm@vger.kernel.org" , "iommu@lists.linux-foundation.org" , David Woodhouse , LKML , Lu Baolu Subject: Re: Plan for /dev/ioasid RFC v2 Message-ID: References: <20210609123919.GA1002214@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210609123919.GA1002214@nvidia.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 09, 2021 at 09:39:19AM -0300, Jason Gunthorpe wrote: > VFIO being group centric has made it very ugly/difficult to inject > device driver specific knowledge into the scheme. This whole API will be complicated and difficult anyway, so no reason to unnecessarily simplify things here. VFIO is group-centric for security/isolation reasons, and since IOASID is a uAPI it also needs to account for that. In the end the devices which are going to use this will likely have their own group anyway, so things will not get too complicated. > The current approach has the group try to guess the device driver > intention in the vfio type 1 code. > > I want to see this be clean and have the device driver directly tell > the iommu layer what kind of DMA it plans to do, and thus how it needs > the IOMMU and IOASID configured. I am in for the general idea, it simplifies the code. But the kernel still needs to check whether the wishlist from user-space can be fulfilled. > The group is causing all this mess because the group knows nothing > about what the device drivers contained in the group actually want. There are devices in the group, not drivers. > Further being group centric eliminates the possibility of working in > cases like !ACS. How do I use PASID functionality of a device behind a > !ACS switch if the uAPI forces all IOASID's to be linked to a group, > not a device? You don't use it, because it is not secure for devices which are not behind an ACS bridge. > Device centric with an report that "all devices in the group must use > the same IOASID" covers all the new functionality, keep the old, and > has a better chance to keep going as a uAPI into the future. If all devices in the group have to use the same IOASID anyway, we can just as well force it by making the interface group-centric. 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_RED 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 8E3D2C48BCF for ; Wed, 9 Jun 2021 13:32:45 +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 47B416108D for ; Wed, 9 Jun 2021 13:32:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 47B416108D 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 17EE883C82; Wed, 9 Jun 2021 13:32:45 +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 gPvbxarWnieH; Wed, 9 Jun 2021 13:32:44 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp1.osuosl.org (Postfix) with ESMTPS id F01AB83C83; Wed, 9 Jun 2021 13:32:43 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9BE9DC000E; Wed, 9 Jun 2021 13:32:43 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id BA96AC000B for ; Wed, 9 Jun 2021 13:32:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 9E6D360680 for ; Wed, 9 Jun 2021 13:32:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71L3YP4xGm4P for ; Wed, 9 Jun 2021 13:32:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from theia.8bytes.org (8bytes.org [IPv6:2a01:238:4383:600:38bc:a715:4b6d:a889]) by smtp3.osuosl.org (Postfix) with ESMTPS id C597A60672 for ; Wed, 9 Jun 2021 13:32:39 +0000 (UTC) Received: by theia.8bytes.org (Postfix, from userid 1000) id 7774036A; Wed, 9 Jun 2021 15:32:35 +0200 (CEST) Date: Wed, 9 Jun 2021 15:32:34 +0200 From: Joerg Roedel To: Jason Gunthorpe Subject: Re: Plan for /dev/ioasid RFC v2 Message-ID: References: <20210609123919.GA1002214@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210609123919.GA1002214@nvidia.com> Cc: "kvm@vger.kernel.org" , Jason Wang , Kirti Wankhede , Jean-Philippe Brucker , "Jiang, Dave" , "Raj, Ashok" , Jonathan Corbet , "Tian, Kevin" , "parav@mellanox.com" , "Alex Williamson \(alex.williamson@redhat.com\)" , "Enrico Weigelt, metux IT consult" , David Gibson , Robin Murphy , LKML , Shenming Lu , "iommu@lists.linux-foundation.org" , Paolo Bonzini , David Woodhouse 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 Wed, Jun 09, 2021 at 09:39:19AM -0300, Jason Gunthorpe wrote: > VFIO being group centric has made it very ugly/difficult to inject > device driver specific knowledge into the scheme. This whole API will be complicated and difficult anyway, so no reason to unnecessarily simplify things here. VFIO is group-centric for security/isolation reasons, and since IOASID is a uAPI it also needs to account for that. In the end the devices which are going to use this will likely have their own group anyway, so things will not get too complicated. > The current approach has the group try to guess the device driver > intention in the vfio type 1 code. > > I want to see this be clean and have the device driver directly tell > the iommu layer what kind of DMA it plans to do, and thus how it needs > the IOMMU and IOASID configured. I am in for the general idea, it simplifies the code. But the kernel still needs to check whether the wishlist from user-space can be fulfilled. > The group is causing all this mess because the group knows nothing > about what the device drivers contained in the group actually want. There are devices in the group, not drivers. > Further being group centric eliminates the possibility of working in > cases like !ACS. How do I use PASID functionality of a device behind a > !ACS switch if the uAPI forces all IOASID's to be linked to a group, > not a device? You don't use it, because it is not secure for devices which are not behind an ACS bridge. > Device centric with an report that "all devices in the group must use > the same IOASID" covers all the new functionality, keep the old, and > has a better chance to keep going as a uAPI into the future. If all devices in the group have to use the same IOASID anyway, we can just as well force it by making the interface group-centric. Regards, Joerg _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu