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 937CBC433ED for ; Mon, 17 May 2021 13:40:35 +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 0F6CD610E9 for ; Mon, 17 May 2021 13:40:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0F6CD610E9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca 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=GwGjYbK/LSoYFosRC0B7anKd2XNCGNcyfl6huxmyBzs=; b=R+9vRjQ0yNxdBRkk/7NQXZn2g MtBJ+exyDLRFgwo9hNJgYoUnBm1JllQP5w61IUmMUZ49WQ7LYbObCMCZsnHhP94CJM18cUUj5b5Ip RTHkY2TuQfkVmxtOWfdaIB/tqdE2jhb87Tf8tpW0SjKuYp2ASVsMwn2uPB2EmAOKRJhyp3WTWlRUA FOU9Acg1iRqWinNE4+dJqpi4MI/Cv1hcKz4u/4ArrwQaV92HFWjtr6MHb289pXvi3cBSsXGJdaZkm 4p2azEB9DfUIyCyrR45Zrz/rlJ347LLLJQMLxce1nxNUhIc5pNxQUnvaiTweh2tA49APBa34O2/BN AicPtfP9Q==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lidRS-00F6Kc-Dr; Mon, 17 May 2021 13:37:54 +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 1lidOm-00F65Q-Kp for linux-arm-kernel@desiato.infradead.org; Mon, 17 May 2021 13:35:24 +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=BBi0ImqVgaTdoUmufhblDvqZN98Dv2D+uHBf7NJmKTc=; b=ParnEdJF1flcvuV1bZxtJtlRAd KnD1OvOEWgebYGEhWW73WaSd3meOT0rJFAt/PPb8dOknwAiE2M22HS71/Pp6U9oDA92k9nc4rjUUK iJ9KmChQ42OHCwHY7aQyNOG5LO08JMp6jjBBtSxCThkFQTTPeyo2xuZ36uNfP4bC878LSoUg7kWBy Hzp0TyjFuato8xp/YWTL5DOPhw6hIz0VxqGt11H2eyNA2hqHztl58lHRbG+mXQxTcYZ2XxPuVHUxJ fuyROueyTKdrgpDtW+3/Jq7RiBtqFL4acbVi1PNGvsRrDDHEGQzc265Dt7Eq2oNkrJeHDedixBcmF Y7QdYrxg==; Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lidOg-00DntX-Q0 for linux-arm-kernel@lists.infradead.org; Mon, 17 May 2021 13:35:06 +0000 Received: by mail-qt1-x835.google.com with SMTP id y12so4775899qtx.11 for ; Mon, 17 May 2021 06:35:02 -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=BBi0ImqVgaTdoUmufhblDvqZN98Dv2D+uHBf7NJmKTc=; b=fI4KjnpIUUKpAjz0x9Mzd07Rv5ptsOe1rhaTupiA8hmF87geY5yzv1KFjhj2KlQtNN 9jwlCBJI1kXnwXZpR4fjxnEF/+MvGRBsFtjf5u7IZP8CQ1rdVAtvKWanISFV0QnesOzW 6/AJFleh+D14Vt/LJZKJCdfr4tmhk6BZRTL2608U0hMq1yXvRS9NxoVsfEoOoSsNuVvx vP3nugx7H8NKy7lGHFTc0Hk+IEEMKRAAA2Xp2KtNverN3Z5XYxlydV3894Xr7A8P0Zgu bJUehgXTHdO3q1lXucrSXcvp4S9SlNPhgBa47ovmA9FPkZESI3Zj0F5i8X43JgN7CY5m UEgA== 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=BBi0ImqVgaTdoUmufhblDvqZN98Dv2D+uHBf7NJmKTc=; b=XywwNHEUgWgqPnoyXOqTtaqvhwUxECtRFMxMmV76b4Hdq/CSpgG2qrRI87ZU3g3Ns4 ZuW6nWRABC6hbZXxZtSL8DBqgpvjnzGvoUrg61F49Tz2HuOcSCFd+5IxlhX8oHCMWxSb yPwQNhzh99FRSS8mHFsfVCo6LEGkwIDOVeLnclKdsxqaFZVAudI2Vl05umJeEPRNhfyV /BKYcI/sWt93Em60JLau3ESV4mIvQnNGSIM7sgPdOSSWiTBggqZxaiQI9eNaZWqVKb5Y QswBKeM6s8NYIfAWJ/Z06XH09z77eGoKn5pCHV7wHMI5qLfWkeCxUewrUeP7XRAMCoWe SQrg== X-Gm-Message-State: AOAM5333xzIA/GEVmpLKj+ntGOIvQQWF+nXWO4vjz4EUbU+Cbm5CbMZD fTJXNq+4goz5/7DYoKBj9VPwzQ== X-Google-Smtp-Source: ABdhPJxSGyi8nwynzq/W6C6jsXKUHeSS9Dh1cS5HbaxJxw3+c/sfqmRtKrfd7kUKoLlziJIkPGtxdg== X-Received: by 2002:a05:622a:170b:: with SMTP id h11mr42137196qtk.330.1621258501565; Mon, 17 May 2021 06:35:01 -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 g5sm11495475qtm.2.2021.05.17.06.35.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 May 2021 06:35:00 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1lidOe-009Gdr-0u; Mon, 17 May 2021 10:35:00 -0300 Date: Mon, 17 May 2021 10:35:00 -0300 From: Jason Gunthorpe To: Joerg Roedel 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: <20210517133500.GP1096940@ziepe.ca> References: <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: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210517_063503_080049_993475D3 X-CRM114-Status: GOOD ( 33.68 ) 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 02:53:16PM +0200, Joerg Roedel wrote: > 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. There world is a lot bigger than just mdev and vfio. > > 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. Do I have to type PASID/stream id/etc/etc in every place? We all know this is gerenal, it is why Intel is picking IOASID for the uAPI name. > 2) An mdev is not a restriction. It is an abstraction with which > other parts of the kernel can work. mdev is really gross, new things should avoid using it. It is also 100% VFIO specific and should never be used outside VFIO. My recent work significantly eliminates the need for mdev at all, the remaining gaps have to do with the way mdev hackily overrides the iommu mechanisms in VFIO. Tying any decision to the assumption that mdev will, or even should, continue is not aligned with the direction things are going. > > 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. 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. In this case the mdev specific auxdomain for PASID use is replaced by sane /dev/ioasid objects - and how that gets implemented through the iommu layer would still be a big TBD. Though I can't forsee any quality implementation of /dev/ioasid being driven by a one io page table per struct device scheme. Hopefully Intel will make the reasons why, and the use cases supporting the desgin, clear in their RFC. > 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. Expect mdev is basically legacy too. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel