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=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_RED autolearn=ham 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 9420EC433DB for ; Thu, 25 Mar 2021 17:23:32 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (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 3FBB761A28 for ; Thu, 25 Mar 2021 17:23:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FBB761A28 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 88E5584A4A; Thu, 25 Mar 2021 17:23:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FeZ-oYW7S2q; Thu, 25 Mar 2021 17:23:30 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp1.osuosl.org (Postfix) with ESMTP id 449C6848FA; Thu, 25 Mar 2021 17:23:30 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 00435C000D; Thu, 25 Mar 2021 17:23:30 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id F0764C000A for ; Thu, 25 Mar 2021 17:23:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id CDB6C84A3F for ; Thu, 25 Mar 2021 17:23:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98s06hC9JgrA for ; Thu, 25 Mar 2021 17:23:27 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp1.osuosl.org (Postfix) with ESMTPS id 15D98848FA for ; Thu, 25 Mar 2021 17:23:27 +0000 (UTC) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9060461A01; Thu, 25 Mar 2021 17:23:26 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lPThc-003nDC-DO; Thu, 25 Mar 2021 17:23:24 +0000 Date: Thu, 25 Mar 2021 17:23:23 +0000 Message-ID: <871rc3rvuc.wl-maz@kernel.org> From: Marc Zyngier To: Megha Dey Subject: Re: [Patch V2 08/13] genirq: Set auxiliary data for an interrupt In-Reply-To: <1614370277-23235-9-git-send-email-megha.dey@intel.com> References: <1614370277-23235-1-git-send-email-megha.dey@intel.com> <1614370277-23235-9-git-send-email-megha.dey@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: megha.dey@intel.com, tglx@linutronix.de, linux-kernel@vger.kernel.org, dave.jiang@intel.com, ashok.raj@intel.com, kevin.tian@intel.com, dwmw@amazon.co.uk, x86@kernel.org, tony.luck@intel.com, dan.j.williams@intel.com, jgg@mellanox.com, kvm@vger.kernel.org, iommu@lists.linux-foundation.org, alex.williamson@redhat.com, bhelgaas@google.com, linux-pci@vger.kernel.org, baolu.lu@linux.intel.com, ravi.v.shankar@intel.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: alex.williamson@redhat.com, kevin.tian@intel.com, tony.luck@intel.com, dave.jiang@intel.com, ashok.raj@intel.com, kvm@vger.kernel.org, ravi.v.shankar@intel.com, linux-pci@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, jgg@mellanox.com, bhelgaas@google.com, tglx@linutronix.de, dan.j.williams@intel.com, dwmw@amazon.co.uk X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Fri, 26 Feb 2021 20:11:12 +0000, Megha Dey wrote: > > Introduce a new function pointer in the irq_chip structure(irq_set_auxdata) > which is responsible for updating data which is stored in a shared register > or data storage. For example, the idxd driver uses the auxiliary data API > to enable/set and disable PASID field that is in the IMS entry (introduced > in a later patch) and that data are not typically present in MSI entry. > > Reviewed-by: Tony Luck > Signed-off-by: Megha Dey > --- > include/linux/interrupt.h | 2 ++ > include/linux/irq.h | 4 ++++ > kernel/irq/manage.c | 32 ++++++++++++++++++++++++++++++++ > 3 files changed, 38 insertions(+) > > diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h > index 967e257..461ed1c 100644 > --- a/include/linux/interrupt.h > +++ b/include/linux/interrupt.h > @@ -496,6 +496,8 @@ extern int irq_get_irqchip_state(unsigned int irq, enum irqchip_irq_state which, > extern int irq_set_irqchip_state(unsigned int irq, enum irqchip_irq_state which, > bool state); > > +int irq_set_auxdata(unsigned int irq, unsigned int which, u64 val); > + > #ifdef CONFIG_IRQ_FORCED_THREADING > # ifdef CONFIG_PREEMPT_RT > # define force_irqthreads (true) > diff --git a/include/linux/irq.h b/include/linux/irq.h > index 2efde6a..fc19f32 100644 > --- a/include/linux/irq.h > +++ b/include/linux/irq.h > @@ -491,6 +491,8 @@ static inline irq_hw_number_t irqd_to_hwirq(struct irq_data *d) > * irq_request_resources > * @irq_compose_msi_msg: optional to compose message content for MSI > * @irq_write_msi_msg: optional to write message content for MSI > + * @irq_set_auxdata: Optional function to update auxiliary data e.g. in > + * shared registers > * @irq_get_irqchip_state: return the internal state of an interrupt > * @irq_set_irqchip_state: set the internal state of a interrupt > * @irq_set_vcpu_affinity: optional to target a vCPU in a virtual machine > @@ -538,6 +540,8 @@ struct irq_chip { > void (*irq_compose_msi_msg)(struct irq_data *data, struct msi_msg *msg); > void (*irq_write_msi_msg)(struct irq_data *data, struct msi_msg *msg); > > + int (*irq_set_auxdata)(struct irq_data *data, unsigned int which, u64 auxval); > + > int (*irq_get_irqchip_state)(struct irq_data *data, enum irqchip_irq_state which, bool *state); > int (*irq_set_irqchip_state)(struct irq_data *data, enum irqchip_irq_state which, bool state); > > diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c > index 85ede4e..68ff559 100644 > --- a/kernel/irq/manage.c > +++ b/kernel/irq/manage.c > @@ -2860,3 +2860,35 @@ bool irq_check_status_bit(unsigned int irq, unsigned int bitmask) > return res; > } > EXPORT_SYMBOL_GPL(irq_check_status_bit); > + > +/** > + * irq_set_auxdata - Set auxiliary data > + * @irq: Interrupt to update > + * @which: Selector which data to update > + * @auxval: Auxiliary data value > + * > + * Function to update auxiliary data for an interrupt, e.g. to update data > + * which is stored in a shared register or data storage (e.g. IMS). > + */ > +int irq_set_auxdata(unsigned int irq, unsigned int which, u64 val) This looks to me like a massively generalised version of irq_set_irqchip_state(), only without any defined semantics when it comes to the 'which' state, making it look like the irqchip version of an ioctl. We also have the irq_set_vcpu_affinity() callback that is used to perpetrate all sort of sins (and I have abused this interface more than I should admit it). Can we try and converge on a single interface that allows for "side-band state" to be communicated, with documented state? > +{ > + struct irq_desc *desc; > + struct irq_data *data; > + unsigned long flags; > + int res = -ENODEV; > + > + desc = irq_get_desc_buslock(irq, &flags, 0); > + if (!desc) > + return -EINVAL; > + > + for (data = &desc->irq_data; data; data = irqd_get_parent_data(data)) { > + if (data->chip->irq_set_auxdata) { > + res = data->chip->irq_set_auxdata(data, which, val); And this is where things can break: because you don't define what 'which' is, you can end-up with two stacked layers clashing in their interpretation of 'which', potentially doing the wrong thing. Short of having a global, cross architecture definition of all the possible states, this is frankly dodgy. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu