From: Stefano Stabellini <sstabellini@kernel.org>
To: jgross@suse.com, boris.ostrovsky@oracle.com
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
"Andrew Cooper" <Andrew.Cooper3@citrix.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
julien.grall@gmail.com, "Julien Grall" <julien.grall@arm.com>,
"Jan Beulich" <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>,
"Dave P Martin" <dave.martin@arm.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] xen/evtchn and forced threaded irq
Date: Mon, 27 Apr 2020 16:20:11 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.21.2004271552430.29217@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <CAF3u54Ct7nBjoLw9Vzb=aZVu=N5Ccp5_k6GxLo_ZSA=YCsco6A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]
On Thu, 21 Feb 2019, Julien Grall wrote:
> Hi Roger,
>
> On Thu, 21 Feb 2019, 08:08 Roger Pau Monné, <roger.pau@citrix.com> wrote:
> FWIW, you can also mask the interrupt while waiting for the thread to
> execute the interrupt handler. Ie:
>
>
> Thank you for providing steps, however where would the masking be done? By the irqchip or a custom solution?
>
>
> 1. Interrupt injected
> 2. Execute guest event channel callback
> 3. Scan for pending interrupts
> 4. Mask interrupt
> 5. Clear pending field
> 6. Queue threaded handler
> 7. Go to 3 until all interrupts are drained
> [...]
> 8. Execute interrupt handler in thread
> 9. Unmask interrupt
>
> That should prevent you from stacking interrupts?
Sorry for coming late to the thread, and thanks Julien for pointing it
out to me. I am afraid I was the one to break the flow back in 2011 with
the following commit:
7e186bdd0098 xen: do not clear and mask evtchns in __xen_evtchn_do_upcall
Oops :-)
Xen event channels have their own workflow; the one Roger wrote above.
They used to be handled using handle_fasteoi_irq until 7e186bdd0098,
then I switched (almost) all of them to handle_edge_irq.
Looking closely at irq handling again, it doesn't look like we can do
what we need with handle_edge_irq today: we can't mask the event channel
before clearing it. But we can do that if we go back to using
handle_fasteoi_irq.
In fact, I managed to verify that LinuxRT works fine as dom0 with the
attached dynamic.patch that switches back xen_dynamic_chip IRQs to
handle_fasteoi_irq.
From the rest of this thread, it looks like the issue might appear with
PIRQs as well. Thus, I wrote a second patch pirqs.patch to switch back
to handle_fasteoi_irq PIRQs as well. However, Xen on ARM does not use
PIRQs so I couldn't test it at all. I would appreciate if Boris/Juegen
tested it. Let me know what you want me to do with the second patch.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff; name=dynamic.patch, Size: 2643 bytes --]
From ce26c371a8ff7b49c98a3b8c7b57199154cbca59 Mon Sep 17 00:00:00 2001
From: Stefano Stabellini <sstabellini@kernel.org>
Date: Mon, 27 Apr 2020 16:15:26 -0700
Subject: [PATCH] xen: use handle_fasteoi_irq to handle xen events
When handling Xen events, we need to make sure the following sequence is
followed:
- mask event
- handle event and clear event (the order does not matter)
- unmask event
It is not possible to implement this flow with handle_edge_irq, so
switch back to handle_fasteoi_irq. Please note that Xen event irqs are
ONESHOT. Also note that handle_fasteoi_irq was in-use before the
following commit, that is partially reverted by this patch:
7e186bdd0098 xen: do not clear and mask evtchns in __xen_evtchn_do_upcall
PIRQ handling is left unchanged.
This patch fixes a domU hang observed when using LinuxRT as dom0 kernel.
Link: https://lore.kernel.org/lkml/5e256d9a-572c-e01e-7706-407f99245b00@arm.com/
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
---
drivers/xen/events/events_base.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 499eff7d3f65..5f9b8104dbcf 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -845,7 +845,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
goto out;
irq_set_chip_and_handler_name(irq, &xen_dynamic_chip,
- handle_edge_irq, "event");
+ handle_fasteoi_irq, "event");
ret = xen_irq_info_evtchn_setup(irq, evtchn);
if (ret < 0) {
@@ -978,7 +978,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu, bool percpu)
handle_percpu_irq, "virq");
else
irq_set_chip_and_handler_name(irq, &xen_dynamic_chip,
- handle_edge_irq, "virq");
+ handle_fasteoi_irq, "virq");
bind_virq.virq = virq;
bind_virq.vcpu = xen_vcpu_nr(cpu);
@@ -1377,12 +1377,6 @@ static void ack_dynirq(struct irq_data *data)
clear_evtchn(evtchn);
}
-static void mask_ack_dynirq(struct irq_data *data)
-{
- disable_dynirq(data);
- ack_dynirq(data);
-}
-
static int retrigger_dynirq(struct irq_data *data)
{
unsigned int evtchn = evtchn_from_irq(data->irq);
@@ -1585,8 +1579,7 @@ static struct irq_chip xen_dynamic_chip __read_mostly = {
.irq_mask = disable_dynirq,
.irq_unmask = enable_dynirq,
- .irq_ack = ack_dynirq,
- .irq_mask_ack = mask_ack_dynirq,
+ .irq_eoi = ack_dynirq,
.irq_set_affinity = set_affinity_irq,
.irq_retrigger = retrigger_dynirq,
--
2.17.1
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Type: text/x-diff; name=pirqs.patch, Size: 2492 bytes --]
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 5f9b8104dbcf..57a29c94fefc 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -498,12 +498,6 @@ static void eoi_pirq(struct irq_data *data)
}
}
-static void mask_ack_pirq(struct irq_data *data)
-{
- disable_dynirq(data);
- eoi_pirq(data);
-}
-
static unsigned int __startup_pirq(unsigned int irq)
{
struct evtchn_bind_pirq bind_pirq;
@@ -684,13 +678,9 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi,
}
pirq_query_unmask(irq);
- /* We try to use the handler with the appropriate semantic for the
- * type of interrupt: if the interrupt is an edge triggered
- * interrupt we use handle_edge_irq.
- *
- * On the other hand if the interrupt is level triggered we use
- * handle_fasteoi_irq like the native code does for this kind of
- * interrupts.
+ /* We use handle_fasteoi_irq for PIRQs because we want to keep
+ * the evtchn masked while handling and clearing the event.
+ * Unmasking the evtchn should only happen after clearing it.
*
* Depending on the Xen version, pirq_needs_eoi might return true
* not only for level triggered interrupts but for edge triggered
@@ -699,12 +689,8 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi,
* hasn't received an eoi yet. Therefore using the fasteoi handler
* is the right choice either way.
*/
- if (shareable)
- irq_set_chip_and_handler_name(irq, &xen_pirq_chip,
- handle_fasteoi_irq, name);
- else
- irq_set_chip_and_handler_name(irq, &xen_pirq_chip,
- handle_edge_irq, name);
+ irq_set_chip_and_handler_name(irq, &xen_pirq_chip,
+ handle_fasteoi_irq, name);
out:
mutex_unlock(&irq_mapping_update_lock);
@@ -739,7 +725,7 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc,
goto out;
for (i = 0; i < nvec; i++) {
- irq_set_chip_and_handler_name(irq + i, &xen_pirq_chip, handle_edge_irq, name);
+ irq_set_chip_and_handler_name(irq + i, &xen_pirq_chip, handle_fasteoi_irq, name);
ret = xen_irq_info_pirq_setup(irq + i, 0, pirq + i, 0, domid,
i == 0 ? 0 : PIRQ_MSI_GROUP);
@@ -1596,9 +1582,7 @@ static struct irq_chip xen_pirq_chip __read_mostly = {
.irq_mask = disable_dynirq,
.irq_unmask = enable_dynirq,
- .irq_ack = eoi_pirq,
.irq_eoi = eoi_pirq,
- .irq_mask_ack = mask_ack_pirq,
.irq_set_affinity = set_affinity_irq,
--
2.17.1
next prev parent reply other threads:[~2020-04-27 23:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5e256d9a-572c-e01e-7706-407f99245b00@arm.com>
2019-02-20 0:02 ` xen/evtchn and forced threaded irq Boris Ostrovsky
[not found] ` <20190220000209.GA4091@localhost.localdomain>
2019-02-20 14:15 ` Julien Grall
[not found] ` <a872d480-9f1b-6cd7-e507-ac4fcdf705af@arm.com>
2019-02-20 17:07 ` Boris Ostrovsky
[not found] ` <21214d47-9c68-e6bf-007a-4047cc2b02f9@oracle.com>
2019-02-20 18:05 ` Julien Grall
[not found] ` <8f7445d7-fa50-f3e9-44f5-cc2aebd020f4@arm.com>
2019-02-20 20:04 ` Boris Ostrovsky
[not found] ` <15bc52cb-82d8-4d2c-e5a8-c6ae8de90276@oracle.com>
2019-02-20 20:46 ` Julien Grall
[not found] ` <5df8888a-4a29-fccd-bac2-a9c170244029@arm.com>
2019-02-20 21:46 ` Boris Ostrovsky
[not found] ` <1574a7fe-a5ac-4bc2-d3f0-967d8d01e5f1@oracle.com>
2019-02-20 22:03 ` Julien Grall
[not found] ` <1100e6b1-6fa8-06f0-8ecc-b0699a2ce5f4@arm.com>
2019-02-21 8:07 ` Roger Pau Monné
[not found] ` <20190221080752.zy2qlzb4vi7tbu3p@Air-de-Roger>
2019-02-21 8:38 ` Julien Grall
2019-02-21 8:52 ` Juergen Gross
2019-02-21 9:14 ` Roger Pau Monné
[not found] ` <20190221091431.vqi53op37mvhi25z@Air-de-Roger>
2019-02-21 20:46 ` Julien Grall
2020-04-27 23:20 ` Stefano Stabellini [this message]
2019-02-22 11:44 ` Jan Beulich
2019-02-22 12:38 ` Oleksandr Andrushchenko
[not found] ` <f7e78bf6-6e65-6d6c-c1ad-dca7f1e66b17@gmail.com>
2019-02-22 13:33 ` Julien Grall
[not found] ` <fe44917f-bbe9-3e0e-fdda-2eb4db9f25c2@arm.com>
2019-02-25 13:24 ` Oleksandr Andrushchenko
[not found] ` <13a9616c-2d9a-f90b-3358-f2dcadbbb64d@gmail.com>
2019-02-25 13:55 ` Julien Grall
[not found] ` <dbfd87e9-48fc-f641-9e24-ddb6c4f61135@arm.com>
2019-02-25 14:08 ` Oleksandr Andrushchenko
[not found] ` <1aeda04d-3420-fa50-ad33-a0b3e981f5e4@gmail.com>
2019-02-25 15:26 ` Julien Grall
2019-02-26 9:14 ` Roger Pau Monné
[not found] ` <20190226091420.klgldhotiecezw6h@Air-de-Roger>
2019-02-26 9:30 ` Andrew Cooper
[not found] ` <038b837c-63c0-afb7-ca7b-75f61af7518e@citrix.com>
2019-02-26 9:44 ` Roger Pau Monné
2019-02-26 9:45 ` Paul Durrant
[not found] ` <20190226094459.33y2ygrjei3sf3gk@Air-de-Roger>
2019-02-26 10:03 ` Julien Grall
[not found] ` <21c331d5-0cfa-6f7e-3db4-40b7ece45bc8@arm.com>
2019-02-26 10:17 ` Roger Pau Monné
[not found] ` <20190226101721.kh5vbrqdlnrtvhwh@Air-de-Roger>
2019-02-26 10:26 ` Julien Grall
[not found] ` <cdd5781c-3a60-b9f7-205f-fadeee88206e@arm.com>
2019-02-26 11:02 ` Roger Pau Monné
[not found] ` <20190226110231.46luhevhlmefdldo@Air-de-Roger>
2019-02-27 11:09 ` Julien Grall
2019-02-21 8:17 ` Juergen Gross
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=alpine.DEB.2.21.2004271552430.29217@sstabellini-ThinkPad-T480s \
--to=sstabellini@kernel.org \
--cc=Andrew.Cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=dave.martin@arm.com \
--cc=jgross@suse.com \
--cc=julien.grall@arm.com \
--cc=julien.grall@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).