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 1024AC48BCD for ; Wed, 9 Jun 2021 13:32:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EB2C66124C for ; Wed, 9 Jun 2021 13:32:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233265AbhFINee (ORCPT ); Wed, 9 Jun 2021 09:34:34 -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: kvm@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