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 A7368C433ED for ; Mon, 17 May 2021 12:22:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8A43A61241 for ; Mon, 17 May 2021 12:22:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234618AbhEQMX2 (ORCPT ); Mon, 17 May 2021 08:23:28 -0400 Received: from 8bytes.org ([81.169.241.247]:39434 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230230AbhEQMXY (ORCPT ); Mon, 17 May 2021 08:23:24 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id C5EF52E7; Mon, 17 May 2021 14:22:07 +0200 (CEST) Date: Mon, 17 May 2021 14:22:06 +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-1-hch@lst.de> <20210510065405.2334771-4-hch@lst.de> <20210510155454.GA1096940@ziepe.ca> <20210513120058.GG1096940@ziepe.ca> <20210514121925.GI1096940@ziepe.ca> <20210514133143.GK1096940@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210514133143.GK1096940@ziepe.ca> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, May 14, 2021 at 10:31:43AM -0300, Jason Gunthorpe wrote: > There is no place for "domain as a carrier of PASID" > there. mdev_device should NOT participate in the IOMMU layer because > it is NOT a HW device. Trying to warp mdev_device into an IOMMU > presence is already the source of a lot of this hacky code. Having the mdev abstraction is way better than making the IOMMU code IOASID aware. The later requires either new parameters to existing functions or new functions. With the mdev abstraction no new functions are needed in the core API. 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. We are not there yet, but I think this is a cleaner abstraction than making the IOMMU-API ioasid-aware. Also because it separates the details of device-partitioning nicely from the IOMMU core code. > To juggle multiple IOASID per HW device the IOMMU API obviously has to > be made IOASID aware. It can't just blindly assume that a struct > device implies the single IOASID to use and hope for the best. The one-device<->one address-space idea is blindly assumed. Simply because the vast amount of devices out there work that way. When ioasids come into the game this changes of course, but we can work that out based on how the ioasids are used. For device partitioning the mdev abstraction work well if it is correctly implemented. The other use-case is device-access to user-space memory, and that is a completely different story. > IOASID represents the IOVA address space. No, when it comes to the IOMMU-API, a domain represents an address space. > Two concepts that represent the same thing is not great :) Agreed, so an IOASID should be an IOMMU-domain, if its not used for passing an mm_struct to a device. Regards, Joerg