Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1736802rwb; Thu, 17 Nov 2022 00:55:38 -0800 (PST) X-Google-Smtp-Source: AA0mqf5v/CX9dvKbc0UOSVw/ImpNGDkxIi4BzQwU3I/hYyUo87xhk3Gb4ZjITOQ7XFRBgSOQ4ozd X-Received: by 2002:a17:906:950a:b0:7ab:2559:8bc4 with SMTP id u10-20020a170906950a00b007ab25598bc4mr1238142ejx.682.1668675338350; Thu, 17 Nov 2022 00:55:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668675338; cv=none; d=google.com; s=arc-20160816; b=j9CVlBMzSmLphtOt9tCiMoH89pgm5BsAef4hFGhpAhd2IDYIfC4na/6L1ypGk3QQA9 6dic5oaVjumBpJ/qx0k5jP6eaiBzDqRuwD9jTn9cag8sj/AQF0X5lFZSRFKXIKPodvbx JybTW3VAjLtIo/Ld/PreqIy63j7sHB7f8TekUjTOffY6j10yKP75Dw2LyhrtruvAs7MH HZMmWi5JyO5UiAtMhMQ3KBpsW8eaDoifvB9pem2xCC0bDxXZ3zpap63/SanaSg+wFil4 1wwot38+QUwGVfkpPuxLbk6Cu8ZkqdT2I7G1r6VHYO92sMYNjKPq0Olh/+xzoVMOa3zP YiAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=MFD4940PdGeyc4AycwTJ7Rt3IIqMoidCx43MEiDgKO8=; b=KpUNHqXU7rSpQcnfOs70PpCmcLO14VK9fyCwVMd5mrfm/Li+ENKv3mw/356r++nd35 IpTDypiB0H15NVLAQXtoBL+AAYxy33KsXIrEBZmnXBZYcu4Hl1qza7ielluyK460I2ZZ bTn1OBDedy/+3IbjP3dIwYwFeG86qH64QLbS9UYVjpfDftWog4stRru+s6IdHFQNiDsq yrq+s/K0XcksoY9VWpSxho8WbWq6W8riQ0fCmGrb1Hzg0FEI/+2YsU0BhKc5Aa6JmdAP p9HopWUjopUekB+0ZCWn4RnWbBcZEDUd0zQVqLfuy/45MG0cOqNNg+M1McdOEZwDVzhg SmpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=kqBokhCH; dkim=neutral (no key) header.i=@linutronix.de header.b=6I0AWqHA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d15-20020aa7d68f000000b0045829a1c0b3si384043edr.251.2022.11.17.00.55.16; Thu, 17 Nov 2022 00:55:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=kqBokhCH; dkim=neutral (no key) header.i=@linutronix.de header.b=6I0AWqHA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234603AbiKQIpo (ORCPT + 93 others); Thu, 17 Nov 2022 03:45:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239635AbiKQIpP (ORCPT ); Thu, 17 Nov 2022 03:45:15 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A2B75131C; Thu, 17 Nov 2022 00:45:05 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1668674702; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MFD4940PdGeyc4AycwTJ7Rt3IIqMoidCx43MEiDgKO8=; b=kqBokhCHAotNmU+TSkdOcKWyM1/wnNaGUoMkcHb+RsWz3C/lY+B79sn+yqdH1QqGEd3dRL OcCowdcDYZFW5GK6M+fp38J6ZWJA3ezRunOT1NGputDqgizUollQLGngmoVPmplggENdsE buR2+9ejzgSdvtNPidMwx51raKkiWoBQhK2syksNlLHd1wcFXMiVgeoXuKyTRoSb4ALfne 8wE+2fwCRu9L0Hhv1GyGtxnx2bi/wnJ8OSSjTAybeCA2CKj9JttEHSN2FmbLvAc8xFsZnx 0zfPD7WR7c7WiHz5T+ZJ7aBg8acagaPnbUl+Z4AQF3hydkEgpxH6CnoNCdIG9w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1668674702; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MFD4940PdGeyc4AycwTJ7Rt3IIqMoidCx43MEiDgKO8=; b=6I0AWqHA8sWxjMJBVsjmucVVAUGrlP0tM/8kTWAYwM21uvnv5BbpzS4ODOCgLPBdmx2BCE OQiobakl4xvr1VDg== To: Jason Gunthorpe Cc: LKML , x86@kernel.org, Joerg Roedel , Will Deacon , linux-pci@vger.kernel.org, Bjorn Helgaas , Lorenzo Pieralisi , Marc Zyngier , Greg Kroah-Hartman , Dave Jiang , Alex Williamson , Kevin Tian , Dan Williams , Logan Gunthorpe , Ashok Raj , Jon Mason , Allen Hubbe , "Ahmed S. Darwish" , Reinette Chatre Subject: Re: [patch 08/20] genirq/msi: Make MSI descriptor iterators device domain aware In-Reply-To: References: <20221111131813.914374272@linutronix.de> <20221111132706.500733944@linutronix.de> <87wn7uo7io.ffs@tglx> Date: Thu, 17 Nov 2022 09:45:02 +0100 Message-ID: <87zgcqm0kx.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 16 2022 at 20:37, Jason Gunthorpe wrote: > On Wed, Nov 16, 2022 at 11:32:15PM +0100, Thomas Gleixner wrote: >> On Wed, Nov 16 2022 at 14:36, Jason Gunthorpe wrote: >> > On Fri, Nov 11, 2022 at 02:56:50PM +0100, Thomas Gleixner wrote: >> >> To support multiple MSI interrupt domains per device it is necessary to >> >> segment the xarray MSI descriptor storage. Each domain gets up to >> >> MSI_MAX_INDEX entries. >> > >> > This kinds of suggests that the new per-device MSI domains should hold >> > this storage instead of per-device xarray? >> >> No, really not. This would create random storage in random driver places >> instead of having a central storage place which is managed by the core >> code. We've had that back in the days when every architecture had it's >> own magic place to store and manage interrupt descriptors. Seen that, >> mopped it up and never want to go back. > > I don't mean shift it into the msi_domain driver logic, I just mean > stick an xarray in the struct msi_domain that the core code, and only > the core code, manages. > > But I suppose, on reflection, the strong reason not to do this is that > the msi_descriptor array is per-device, and while it would work OK > with per-device msi_domains we still have the legacy of global msi > domains and thus still need a per-device place to store the global msi > domain's per-device descriptors. I tried several approaches but all of them ended up having slightly different code pathes and decided to keep everything the same from legacy arch over global MSI and the modern per device MSI models. Due to that some of the constructs are slightly awkward, but the important outcome for me was that I ended up with as many shared code pathes as possible. Having separate code pathes for all variants is for one causing code bloat and what's worse it's a guarantee for divergance and maintenance nightmares. As this is setup/teardown management code and not the fancy hotpath where we really want to spare cycles, I went for the unified model. > You could have as many secondary domains as is required this way. Few > drivers would ever use a secondary domain, so it not really a big deal > for them to hold the pointer lifetime. > >> So what are you concerned about? > > Mostly API clarity, I find it very un-kernly to swap a clear pointer > for an ID #. We loose typing, the APIs become less clear and we now > have to worry about ID allocation policy if we ever need more than 2. I don't see an issue with that. id = msi_create_device_domain(dev, &template, ...); is not much different from: ptr = msi_create_device_domain(dev, &template, ...); But it makes a massive difference vs. encapsulation and pointer leakage. If you have a stale ID then you can't do harm, a stale pointer very much so. Aside of that once pointers are available people insist on fiddling in the guts. As I'm mopping up behind driver writers for the last twenty years now, my confidence in them is pretty close to zero. So I rather be defensive and work towards encapsulation where ever its possible. Interrupts are a source of hard to debug subtle bugs, so taking the tinkerers the tools away to cause them is a good thing IMO. Thanks, tglx