All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Valentin Schneider <valentin.schneider@arm.com>
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: [PATCH v3 02/13] genirq: Define ack_irq() and eoi_irq() helpers
Date: Thu, 12 Aug 2021 15:45:25 +0100	[thread overview]
Message-ID: <87y29690xm.wl-maz@kernel.org> (raw)
In-Reply-To: <877dgq9450.mognet@arm.com>

On Thu, 12 Aug 2021 14:36:11 +0100,
Valentin Schneider <valentin.schneider@arm.com> wrote:
> 
> On 12/08/21 08:49, Marc Zyngier wrote:
> > On Tue, 29 Jun 2021 13:49:59 +0100,
> > Valentin Schneider <valentin.schneider@arm.com> wrote:
> >> +void eoi_irq(struct irq_desc *desc)
> >> +{
> >> +	desc->irq_data.chip->irq_eoi(&desc->irq_data);
> >> +
> >> +	if (desc->irq_data.chip->flags & IRQCHIP_AUTOMASKS_FLOW)
> >> +		irq_state_clr_flow_masked(desc);
> >
> > I just realised that this has a good chance to result in a mess with
> > KVM, and specially the way we let the vGIC deactivate an interrupt
> > directly from the guest, without any SW intervention (the magic HW bit
> > in the LRs).
> >
> 
> I didn't think to consider those. It can't ever be simple, can it...
> 
> > With this, interrupts routed to a guest (such as the timers) will
> > always have the IRQD_IRQ_FLOW_MASKED flag set, which will never be
> > cleared.
> >
> > I wonder whether this have a chance to interact badly with
> > mask/unmask, or with the rest of the flow...
> >
> 
> Isn't it the other way around? That is, eoi_irq() will clear
> IRQD_IRQ_FLOW_MASKED regardless of what happens within chip->irq_eoi(),
> so we would end up with !IRQD_IRQ_FLOW_MASKED even if the (physical) IRQ
> remains Active (irqd_is_forwarded_to_vcpu() case).

Ah, I missed (again) that we always clear the flag, no matter what.

> This does not entirely match reality (if the IRQ is still Active then it is
> still "flow-masked"), but AFAICT this doesn't impact our handling of
> forwarded IRQs: IRQD_IRQ_FLOW_MASKED is only really relevant from ack_irq()
> to eoi_irq(), and deactivation-from-the-guest (propagated via LR.HW=1)
> happens after that.

Right. So we can have an active interrupt that is not flow-masked.
That's counter-intuitive, but that's the GIC architecture for you...

I'll take the series for a ride in -next. If anything breaks, we
should know pretty soon.

Thanks,

	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

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Valentin Schneider <valentin.schneider@arm.com>
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: [PATCH v3 02/13] genirq: Define ack_irq() and eoi_irq() helpers
Date: Thu, 12 Aug 2021 15:45:25 +0100	[thread overview]
Message-ID: <87y29690xm.wl-maz@kernel.org> (raw)
In-Reply-To: <877dgq9450.mognet@arm.com>

On Thu, 12 Aug 2021 14:36:11 +0100,
Valentin Schneider <valentin.schneider@arm.com> wrote:
> 
> On 12/08/21 08:49, Marc Zyngier wrote:
> > On Tue, 29 Jun 2021 13:49:59 +0100,
> > Valentin Schneider <valentin.schneider@arm.com> wrote:
> >> +void eoi_irq(struct irq_desc *desc)
> >> +{
> >> +	desc->irq_data.chip->irq_eoi(&desc->irq_data);
> >> +
> >> +	if (desc->irq_data.chip->flags & IRQCHIP_AUTOMASKS_FLOW)
> >> +		irq_state_clr_flow_masked(desc);
> >
> > I just realised that this has a good chance to result in a mess with
> > KVM, and specially the way we let the vGIC deactivate an interrupt
> > directly from the guest, without any SW intervention (the magic HW bit
> > in the LRs).
> >
> 
> I didn't think to consider those. It can't ever be simple, can it...
> 
> > With this, interrupts routed to a guest (such as the timers) will
> > always have the IRQD_IRQ_FLOW_MASKED flag set, which will never be
> > cleared.
> >
> > I wonder whether this have a chance to interact badly with
> > mask/unmask, or with the rest of the flow...
> >
> 
> Isn't it the other way around? That is, eoi_irq() will clear
> IRQD_IRQ_FLOW_MASKED regardless of what happens within chip->irq_eoi(),
> so we would end up with !IRQD_IRQ_FLOW_MASKED even if the (physical) IRQ
> remains Active (irqd_is_forwarded_to_vcpu() case).

Ah, I missed (again) that we always clear the flag, no matter what.

> This does not entirely match reality (if the IRQ is still Active then it is
> still "flow-masked"), but AFAICT this doesn't impact our handling of
> forwarded IRQs: IRQD_IRQ_FLOW_MASKED is only really relevant from ack_irq()
> to eoi_irq(), and deactivation-from-the-guest (propagated via LR.HW=1)
> happens after that.

Right. So we can have an active interrupt that is not flow-masked.
That's counter-intuitive, but that's the GIC architecture for you...

I'll take the series for a ride in -next. If anything breaks, we
should know pretty soon.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2021-08-12 14:47 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-29 12:49 [PATCH v3 00/13] irqchip/irq-gic: Optimize masking by leveraging EOImode=1 Valentin Schneider
2021-06-29 12:49 ` Valentin Schneider
2021-06-29 12:49 ` [PATCH v3 01/13] genirq: Add chip flag to denote automatic IRQ (un)masking Valentin Schneider
2021-06-29 12:49   ` Valentin Schneider
2021-08-12 15:13   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider
2021-06-29 12:49 ` [PATCH v3 02/13] genirq: Define ack_irq() and eoi_irq() helpers Valentin Schneider
2021-06-29 12:49   ` Valentin Schneider
2021-08-12  7:49   ` Marc Zyngier
2021-08-12  7:49     ` Marc Zyngier
2021-08-12 13:36     ` Valentin Schneider
2021-08-12 13:36       ` Valentin Schneider
2021-08-12 14:45       ` Marc Zyngier [this message]
2021-08-12 14:45         ` Marc Zyngier
2021-08-12 15:13   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider
2021-06-29 12:50 ` [PATCH v3 03/13] genirq: Employ ack_irq() and eoi_irq() where relevant Valentin Schneider
2021-06-29 12:50   ` Valentin Schneider
2021-08-12 15:13   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider
2021-06-29 12:50 ` [PATCH v3 04/13] genirq: Add handle_strict_flow_irq() flow handler Valentin Schneider
2021-06-29 12:50   ` Valentin Schneider
2021-08-12 15:13   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider
2021-06-29 12:50 ` [PATCH v3 05/13] genirq: Let purely flow-masked ONESHOT irqs through unmask_threaded_irq() Valentin Schneider
2021-06-29 12:50   ` Valentin Schneider
2021-08-12  7:26   ` Marc Zyngier
2021-08-12  7:26     ` Marc Zyngier
2021-08-12 13:36     ` Valentin Schneider
2021-08-12 13:36       ` Valentin Schneider
2021-08-12 14:45       ` Marc Zyngier
2021-08-12 14:45         ` Marc Zyngier
2021-08-12 21:38         ` Valentin Schneider
2021-08-12 21:38           ` Valentin Schneider
2021-08-12 15:13   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider
2021-06-29 12:50 ` [PATCH v3 06/13] genirq: Don't mask IRQ within flow handler if IRQ is flow-masked Valentin Schneider
2021-06-29 12:50   ` Valentin Schneider
2021-08-12 15:13   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider
2021-06-29 12:50 ` [PATCH v3 07/13] genirq, irq-gic-v3: Make NMI flow handlers use ->irq_ack() if available Valentin Schneider
2021-06-29 12:50   ` Valentin Schneider
2021-08-12 15:13   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider
2021-06-29 12:50 ` [PATCH v3 08/13] genirq/msi: Provide default .irq_eoi() for MSI chips Valentin Schneider
2021-06-29 12:50   ` Valentin Schneider
2021-08-12 15:13   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider
2021-06-29 12:50 ` [PATCH v3 09/13] irqchip/gic: Rely on MSI default .irq_eoi() Valentin Schneider
2021-06-29 12:50   ` Valentin Schneider
2021-08-12 15:12   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider
2021-06-29 12:50 ` [PATCH v3 10/13] genirq/msi: Provide default .irq_ack() for MSI chips Valentin Schneider
2021-06-29 12:50   ` Valentin Schneider
2021-08-12 15:12   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider
2021-06-29 12:50 ` [PATCH v3 11/13] irqchip/gic: Add .irq_ack() to GIC-based irqchips Valentin Schneider
2021-06-29 12:50   ` Valentin Schneider
2021-08-12 15:12   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider
2021-06-29 12:50 ` [PATCH v3 12/13] irqchip/gic: Convert to handle_strict_flow_irq() Valentin Schneider
2021-06-29 12:50   ` Valentin Schneider
2021-08-12 15:12   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider
2021-06-29 12:50 ` [PATCH v3 13/13] irqchip/gic-v3: " Valentin Schneider
2021-06-29 12:50   ` Valentin Schneider
2021-08-12 15:12   ` [irqchip: irq/irqchip-next] " irqchip-bot for Valentin Schneider

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=87y29690xm.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=tglx@linutronix.de \
    --cc=valentin.schneider@arm.com \
    --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: link
Be 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.