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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E2E8CC61D9B for ; Wed, 22 Nov 2023 17:51:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; 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=/iTILCyzcvMR5YqqIWEDFUQDNcyWi5FTfY89kcuUQnc=; b=jpFj2A9maEP2YA gr62ZCPdCtzh8KzxQrSnPgwhkl9Uw7Iz/HxogFFpYqrs4CPxBc9VwpEDpm/5OjJ9PTnytw7wr8h0U N7OxSiaYud1MWc71mxIVsNcIQwMvxoFX/BM/1boNQ7PLrwy/oO9oc0OJbWLAW0OXMtBts1/SCHSzA BOHfyZ9dAZq491lZuHcYD0LGLINB7AoyUKT+HEF3CuRFHrEEJ4M5QFQBL1OtjGEX+9aK9lFjxZppn l8GKpFJXnh+PkDCsc/qUnrymLM26nttj5kTDlv3NhQkcp+QM24LGU7lBcPUqw3IeZD2nKAVqw4gWe jDH8U3jIYkU5RDQqwMyQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r5rNP-002jiH-21; Wed, 22 Nov 2023 17:51:03 +0000 Received: from mail-oi1-x236.google.com ([2607:f8b0:4864:20::236]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r5rNL-002jfj-25 for linux-arm-kernel@lists.infradead.org; Wed, 22 Nov 2023 17:51:02 +0000 Received: by mail-oi1-x236.google.com with SMTP id 5614622812f47-3b83c4c5aefso50777b6e.1 for ; Wed, 22 Nov 2023 09:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1700675458; x=1701280258; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=nz8V9rweqecmN/L6SV+gBbsJ4Hg3ddyVevYX1Lj6BmI=; b=YncBJehcxIjE9mvtHhbrONWBL19/008l0UAP4qv2qTSaZzoZGt8eq6fXnsm1bfvOrh 74jLq7X+INACOfUHq2u5chfcJMg34cIHf+DZuZqS0bOdClJt9AiNWo6vrxrhTWs+n5Fb 7SlNp65vEQDsTGJwHhevNY1YZrtBl9F9Uz3GMZaYXx297PifAVeauRzYoq7/n+99fHVV VTANYTVozwwwvii3xic2/zsfwN9dHAR1zRCJ7OnOsGP0qWlGjlPlB+GOncU93tVJa6MA B2r+3J7hU33cLxGaomIq315fis3cKoyjaKWFzrGBAwZMTTKe9QTriSRWSvWtlkjeSz9W gYFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700675458; x=1701280258; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nz8V9rweqecmN/L6SV+gBbsJ4Hg3ddyVevYX1Lj6BmI=; b=lqjNoMiBlK2WPKlhb2hNGV0xR0htO+kTSxFwLSSnOxH7Nh++mM0PpbAcBxo1a/Ch72 hKNKQkIXI7r7uFjKv5IgbtYR4bkaCPPdioVqWePSwVpvvk9IX4apqKFncCo4r4O9vieM kGINX7hqcmB++Mc4OW6NS51082MTJdxuOO1sLAnMy9iczcgqKyRvKklfpHD/vPU7F0WH X1bZvTCryoJ29f2Toleqe/uZqmiwBNROOq2URBn0d7MbNf0RFvmMDQMsbWRIJO/5VxtJ tSjhkksQ+YQMn8YZ9zW9M74MlEiLPN7nKeGbBn7+Bd1twWKN4CkRQQTczLGPKZJh5eRY 5XlQ== X-Gm-Message-State: AOJu0Ywds/5usQbLdNV33mrwGVx/5kb/nOwuIVjxh/vwhU5A1HVyvqNN mGR4e54RODpMjWhSXg0pf+hmBQ== X-Google-Smtp-Source: AGHT+IE+sHgWkgjDL3HKxojzOCpNaYYUzNGrbePDWKzfLgoTlvyEA+capCzFwvDnlBFWeg+wqRDriA== X-Received: by 2002:a05:6808:2224:b0:3b8:3ddd:d490 with SMTP id bd36-20020a056808222400b003b83dddd490mr3304098oib.59.1700675457762; Wed, 22 Nov 2023 09:50:57 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-134-23-187.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.134.23.187]) by smtp.gmail.com with ESMTPSA id z19-20020a056808029300b003a78d196acasm7520oic.32.2023.11.22.09.50.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Nov 2023 09:50:56 -0800 (PST) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1r5rNH-001ftT-QO; Wed, 22 Nov 2023 13:50:55 -0400 Date: Wed, 22 Nov 2023 13:50:55 -0400 From: Jason Gunthorpe To: Robin Murphy Cc: Boris Brezillon , Joerg Roedel , iommu@lists.linux.dev, Will Deacon , linux-arm-kernel@lists.infradead.org, Rob Clark , Gaurav Kohli , Steven Price Subject: Re: [PATCH v2 0/2] iommu: Allow passing custom allocators to pgtable drivers Message-ID: <20231122175055.GI10140@ziepe.ca> References: <20231110201652.629b7228@collabora.com> <20231110194215.GR4488@nvidia.com> <20231113101103.1cc05c8c@collabora.com> <20231120140425.GA10140@ziepe.ca> <20231120153838.2166e7b8@collabora.com> <20231120144604.GD10140@ziepe.ca> <20231120161418.5eca178e@collabora.com> <20231120154536.GE10140@ziepe.ca> <6e74bd37-9e10-416e-9fbd-0cebb7948e2b@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6e74bd37-9e10-416e-9fbd-0cebb7948e2b@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231122_095100_021745_0F2E5F96 X-CRM114-Status: GOOD ( 36.03 ) 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 Wed, Nov 22, 2023 at 05:23:34PM +0000, Robin Murphy wrote: > > Gaurav doesn't need a custom allocator, he needs a way to manage > > sharing page table memory with the hypervisor. A different set of ops > > that don't replace the entire allocator would be fine for them. > > > > The issue with taking away the alloc_page is that it complicates the > > ability for the common code to use the struct page fields and more. We > > already know we are going to need those to do some of the things that > > are being asked for, eg RCU freeing and refcounting. > > Oh come on, for all the things you claim are simple, you don't think it's > trivial to make the fancy stuff conditional? (Hint: we already have control > flow all over which is conditional on the cfg and/or calling context, and > that future stuff may well end up wanting to be conditional in its own right > anyway since not all io-pgtable-arm users will need or want it). I really don't want to make it conditional! I'd want to have one common set of radix algorithms shared by the enterprise IOMMUs, so we can actually improve those drivers and get all the special features people want without writing everything 5 times. > > Here I am not talking about perfection, I am concerned about messing > > up work that I now see as important for other iommu drivers related > > things by making a hack for a DRM driver (which as I've said has, > > unravelling these hacks has been traumatic for many of us > > historically) > > In your own words, this is a community effort. You do not own this code, and > you do not get to prevent the community from solving multiple problems they > have now, in a way which is reasonable now, just because *you* don't like > it, and *you* believe it might possibly make it harder to do something at > some indeterminate point in future. Your objection is noted, but as above, I > for one do not see a convincing basis for it anyway. I've said already it is my opinion, if you want to bring another one then you can particpate too. Thank you for noting my objection. > You know what *the community* sees as important? Not having to maintain > multiple copies of near-identical pagetable code, because maintenance is an > established and very real concern. What I heard at LPC is we badly need to stop maintaining independent radix algorithms across at least the enterprise iommu drivers. This was clearly an articulated need for many different people *from the community*. > This is why we have the io-pgtable > library in the first place, and why we adapted io-pgtable-arm to support > panfrost when that came along. If supporting panfrost and panthor as > io-pgtable users really does ever become a practical problem at some point > in the future, we will work to address that problem at that point. You mean Joao or myself will get stuck with it. Not "we". :( > meantime, we can get on with the common goal of making Linux do the things > people want it to do, in the best way that the maintainers are happy to > maintain. This is not "a hack for a DRM driver", it's a simple and > convenient generalisation of part of io-pgtable, in keeping with the design > of io-pgtable (user-provided callbacks are nothing new), and > straightforwardly serving at least two completely different use-cases > already. I've already explained to Boris, and he agreed, that it is the *wrong* generalization because it is implementing a generally useful algorithm in the DRM driver and keeping it out of the core code. If we deliberately do the wrong thing then, yes, it is a hack. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel