From: Valentin Schneider <valentin.schneider@arm.com> To: Marc Zyngier <maz@kernel.org> Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Gleixner <tglx@linutronix.de>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Vincenzo Frascino <vincenzo.frascino@arm.com> Subject: Re: [RFC PATCH v2 09/10] irqchip/gic: Convert to handle_strict_flow_irq() Date: Tue, 15 Jun 2021 16:20:03 +0100 [thread overview] Message-ID: <87lf7bb1ek.mognet@arm.com> (raw) In-Reply-To: <87pmx5g9ud.mognet@arm.com> On 01/06/21 11:25, Valentin Schneider wrote: > On 27/05/21 13:21, Marc Zyngier wrote: >> On Tue, 25 May 2021 18:32:54 +0100, >> Valentin Schneider <valentin.schneider@arm.com> wrote: >>> @@ -1116,8 +1116,16 @@ static void gic_init_chip(struct gic_chip_data *gic, struct device *dev, >>> >>> if (use_eoimode1) { >>> gic->chip.irq_mask = gic_eoimode1_mask_irq; >>> + gic->chip.irq_ack = gic_eoi_irq; >>> gic->chip.irq_eoi = gic_eoimode1_eoi_irq; >>> gic->chip.irq_set_vcpu_affinity = gic_irq_set_vcpu_affinity; >>> + >>> + /* >>> + * eoimode0 shouldn't expose FLOW_MASK because the priority >>> + * drop is undissociable from the deactivation, and we do need >>> + * the priority drop to happen within the flow handler. >>> + */ >>> + gic->chip.flags |= IRQCHIP_AUTOMASKS_FLOW | IRQCHIP_EOI_THREADED; >>> } >>> >>> if (gic == &gic_data[0]) { >> >> How about GICv2M, GICv3-MBI, and the collection of widget that build a >> domain on top of a GIC domain? I'm worried that they now all need >> updating one way or another... >> > > Hmph, that's a good point. It's been a while since I've last stared at the > v2m, I'll go try to page that back in. > It's taken me a while to get back to this, apologies. Here's where I'm at: At the very least these need the +.irq_ack() treatment, same as the ITS chips. We can get around this by giving msi_domain_update_chip_ops() some invoke-first-non-NULL default callbacks, as you've suggested in: http://lore.kernel.org/r/87y2c0s748.wl-maz@kernel.org Now, looking at this made me think about which irq_chip flags are being used where, and, well... PCI-MSI IRQs are deemed 'oneshot safe', but platform-MSI ones aren't. So for instance, if a GICv2M pMSI IRQ gets force-threaded, we'll make it IRQS_ONESHOT. However, this is still just a glorified SPI as all mask, ack and eoi operations will be the root chip's, so we should be able to apply the eoimode=1 automask trickery to it. This won't happen with the current patches, since the ->chip we'll seeing in handle_strict_flow_irq() will be gicv2m_pmsi_irq_chip. We *could* give that one the required flags, but what actually matters for the automask thing are the flags of first chip in the hiearachy that has "proper" ack+eoi callbacks. I don't see a nice way of handling this right now... >> M. >> >> -- >> Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Valentin Schneider <valentin.schneider@arm.com> To: Marc Zyngier <maz@kernel.org> Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Gleixner <tglx@linutronix.de>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Vincenzo Frascino <vincenzo.frascino@arm.com> Subject: Re: [RFC PATCH v2 09/10] irqchip/gic: Convert to handle_strict_flow_irq() Date: Tue, 15 Jun 2021 16:20:03 +0100 [thread overview] Message-ID: <87lf7bb1ek.mognet@arm.com> (raw) In-Reply-To: <87pmx5g9ud.mognet@arm.com> On 01/06/21 11:25, Valentin Schneider wrote: > On 27/05/21 13:21, Marc Zyngier wrote: >> On Tue, 25 May 2021 18:32:54 +0100, >> Valentin Schneider <valentin.schneider@arm.com> wrote: >>> @@ -1116,8 +1116,16 @@ static void gic_init_chip(struct gic_chip_data *gic, struct device *dev, >>> >>> if (use_eoimode1) { >>> gic->chip.irq_mask = gic_eoimode1_mask_irq; >>> + gic->chip.irq_ack = gic_eoi_irq; >>> gic->chip.irq_eoi = gic_eoimode1_eoi_irq; >>> gic->chip.irq_set_vcpu_affinity = gic_irq_set_vcpu_affinity; >>> + >>> + /* >>> + * eoimode0 shouldn't expose FLOW_MASK because the priority >>> + * drop is undissociable from the deactivation, and we do need >>> + * the priority drop to happen within the flow handler. >>> + */ >>> + gic->chip.flags |= IRQCHIP_AUTOMASKS_FLOW | IRQCHIP_EOI_THREADED; >>> } >>> >>> if (gic == &gic_data[0]) { >> >> How about GICv2M, GICv3-MBI, and the collection of widget that build a >> domain on top of a GIC domain? I'm worried that they now all need >> updating one way or another... >> > > Hmph, that's a good point. It's been a while since I've last stared at the > v2m, I'll go try to page that back in. > It's taken me a while to get back to this, apologies. Here's where I'm at: At the very least these need the +.irq_ack() treatment, same as the ITS chips. We can get around this by giving msi_domain_update_chip_ops() some invoke-first-non-NULL default callbacks, as you've suggested in: http://lore.kernel.org/r/87y2c0s748.wl-maz@kernel.org Now, looking at this made me think about which irq_chip flags are being used where, and, well... PCI-MSI IRQs are deemed 'oneshot safe', but platform-MSI ones aren't. So for instance, if a GICv2M pMSI IRQ gets force-threaded, we'll make it IRQS_ONESHOT. However, this is still just a glorified SPI as all mask, ack and eoi operations will be the root chip's, so we should be able to apply the eoimode=1 automask trickery to it. This won't happen with the current patches, since the ->chip we'll seeing in handle_strict_flow_irq() will be gicv2m_pmsi_irq_chip. We *could* give that one the required flags, but what actually matters for the automask thing are the flags of first chip in the hiearachy that has "proper" ack+eoi callbacks. I don't see a nice way of handling this right now... >> M. >> >> -- >> Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-06-15 15:20 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-25 17:32 [RFC PATCH v2 00/10] irqchip/irq-gic: Optimize masking by leveraging EOImode=1 Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 01/10] genirq: Add chip flag to denote automatic IRQ (un)masking Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 02/10] genirq: Define irq_ack() and irq_eoi() helpers Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 20:54 ` kernel test robot 2021-05-27 10:55 ` Marc Zyngier 2021-05-27 10:55 ` Marc Zyngier 2021-05-27 10:58 ` Marc Zyngier 2021-05-27 10:58 ` Marc Zyngier 2021-06-01 10:25 ` Valentin Schneider 2021-06-01 10:25 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 03/10] genirq: Employ ack_irq() and eoi_irq() where relevant Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 04/10] genirq: Add handle_strict_flow_irq() flow handler Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 05/10] genirq: Let purely flow-masked ONESHOT irqs through unmask_threaded_irq() Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 06/10] genirq: Don't mask IRQ within flow handler if IRQ is flow-masked Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 07/10] genirq, irq-gic-v3: Make NMI flow handlers use ->irq_ack() if available Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 08/10] irqchip/gic-v3-its: Use irq_chip_ack_parent() Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-27 12:17 ` Marc Zyngier 2021-05-27 12:17 ` Marc Zyngier 2021-06-01 10:25 ` Valentin Schneider 2021-06-01 10:25 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 09/10] irqchip/gic: Convert to handle_strict_flow_irq() Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-27 12:21 ` Marc Zyngier 2021-05-27 12:21 ` Marc Zyngier 2021-06-01 10:25 ` Valentin Schneider 2021-06-01 10:25 ` Valentin Schneider 2021-06-15 15:20 ` Valentin Schneider [this message] 2021-06-15 15:20 ` Valentin Schneider 2021-05-25 17:32 ` [RFC PATCH v2 10/10] irqchip/gic-v3: " Valentin Schneider 2021-05-25 17:32 ` Valentin Schneider 2021-05-25 17:34 ` [RFC PATCH v2 00/10] irqchip/irq-gic: Optimize masking by leveraging EOImode=1 Valentin Schneider 2021-05-25 17:34 ` Valentin Schneider 2021-05-27 11:17 ` Marc Zyngier 2021-05-27 11:17 ` Marc Zyngier 2021-06-01 10:25 ` Valentin Schneider 2021-06-01 10:25 ` Valentin Schneider 2021-06-03 15:32 ` Valentin Schneider 2021-06-03 15:32 ` Valentin Schneider 2021-06-08 15:29 ` Marc Zyngier 2021-06-08 15:29 ` Marc Zyngier 2021-06-08 17:58 ` Lorenzo Pieralisi 2021-06-08 17:58 ` Lorenzo Pieralisi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87lf7bb1ek.mognet@arm.com \ --to=valentin.schneider@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lorenzo.pieralisi@arm.com \ --cc=maz@kernel.org \ --cc=tglx@linutronix.de \ --cc=vincenzo.frascino@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.