All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	lorenzo.pieralisi@arm.com, Andrew.Murray@arm.com,
	yuzenghui@huawei.com, Heyi Guo <guoheyi@huawei.com>
Subject: [PATCH v2 09/11] irqchip/gic-v3-its: Synchronise INT/CLEAR commands targetting a VLPI using VSYNC
Date: Fri,  8 Nov 2019 16:58:03 +0000	[thread overview]
Message-ID: <20191108165805.3071-10-maz@kernel.org> (raw)
In-Reply-To: <20191108165805.3071-1-maz@kernel.org>

We have so far always injected/cleared VLPIs using either
INT+SYNC or CLEAR+SYNC sequences, but that's pretty wrong
for two reasons:

- SYNC only synchronises physical LPIs
- The collection ID that for the associated LPI doesn't match
  the redistributor the vPE is associated with

Instead, send an {INT,CLEAR}+VSYNC for forwarded LPIs, ensuring
that the ITS synchronises against the virtual pending table.

Reported-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 drivers/irqchip/irq-gic-v3-its.c | 79 ++++++++++++++++++++++++++++++--
 1 file changed, 75 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 427496b7baf6..a83828e983ff 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -718,6 +718,42 @@ static struct its_vpe *its_build_vinv_cmd(struct its_node *its,
 	return valid_vpe(its, map->vpe);
 }
 
+static struct its_vpe *its_build_vint_cmd(struct its_node *its,
+					  struct its_cmd_block *cmd,
+					  struct its_cmd_desc *desc)
+{
+	struct its_vlpi_map *map;
+
+	map = dev_event_to_vlpi_map(desc->its_int_cmd.dev,
+				    desc->its_int_cmd.event_id);
+
+	its_encode_cmd(cmd, GITS_CMD_INT);
+	its_encode_devid(cmd, desc->its_int_cmd.dev->device_id);
+	its_encode_event_id(cmd, desc->its_int_cmd.event_id);
+
+	its_fixup_cmd(cmd);
+
+	return valid_vpe(its, map->vpe);
+}
+
+static struct its_vpe *its_build_vclear_cmd(struct its_node *its,
+					    struct its_cmd_block *cmd,
+					    struct its_cmd_desc *desc)
+{
+	struct its_vlpi_map *map;
+
+	map = dev_event_to_vlpi_map(desc->its_clear_cmd.dev,
+				    desc->its_clear_cmd.event_id);
+
+	its_encode_cmd(cmd, GITS_CMD_CLEAR);
+	its_encode_devid(cmd, desc->its_clear_cmd.dev->device_id);
+	its_encode_event_id(cmd, desc->its_clear_cmd.event_id);
+
+	its_fixup_cmd(cmd);
+
+	return valid_vpe(its, map->vpe);
+}
+
 static u64 its_cmd_ptr_to_offset(struct its_node *its,
 				 struct its_cmd_block *ptr)
 {
@@ -1098,6 +1134,34 @@ static void its_send_vinv(struct its_device *dev, u32 event_id)
 	its_send_single_vcommand(dev->its, its_build_vinv_cmd, &desc);
 }
 
+static void its_send_vint(struct its_device *dev, u32 event_id)
+{
+	struct its_cmd_desc desc;
+
+	/*
+	 * There is no real VINT command. This is just a normal INT,
+	 * with a VSYNC instead of a SYNC.
+	 */
+	desc.its_int_cmd.dev = dev;
+	desc.its_int_cmd.event_id = event_id;
+
+	its_send_single_vcommand(dev->its, its_build_vint_cmd, &desc);
+}
+
+static void its_send_vclear(struct its_device *dev, u32 event_id)
+{
+	struct its_cmd_desc desc;
+
+	/*
+	 * There is no real VCLEAR command. This is just a normal CLEAR,
+	 * with a VSYNC instead of a SYNC.
+	 */
+	desc.its_clear_cmd.dev = dev;
+	desc.its_clear_cmd.event_id = event_id;
+
+	its_send_single_vcommand(dev->its, its_build_vclear_cmd, &desc);
+}
+
 /*
  * irqchip functions - assumes MSI, mostly.
  */
@@ -1291,10 +1355,17 @@ static int its_irq_set_irqchip_state(struct irq_data *d,
 	if (which != IRQCHIP_STATE_PENDING)
 		return -EINVAL;
 
-	if (state)
-		its_send_int(its_dev, event);
-	else
-		its_send_clear(its_dev, event);
+	if (irqd_is_forwarded_to_vcpu(d)) {
+		if (state)
+			its_send_vint(its_dev, event);
+		else
+			its_send_vclear(its_dev, event);
+	} else {
+		if (state)
+			its_send_int(its_dev, event);
+		else
+			its_send_clear(its_dev, event);
+	}
 
 	return 0;
 }
-- 
2.20.1


  parent reply	other threads:[~2019-11-08 16:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08 16:57 [PATCH v2 00/11] irqchip/gic-v3-its: Cleanup and fixes for Linux 5.5 Marc Zyngier
2019-11-08 16:57 ` [PATCH v2 01/11] irqchip/gic-v3-its: Free collection mapping on device teardown Marc Zyngier
2019-11-09  8:26   ` Zenghui Yu
2019-11-20 13:21   ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2019-11-08 16:57 ` [PATCH v2 02/11] irqchip/gic-v3-its: Factor out wait_for_syncr primitive Marc Zyngier
2019-11-08 16:57 ` [PATCH v2 03/11] irqchip/gic-v3-its: Allow LPI invalidation via the DirectLPI interface Marc Zyngier
2019-11-09  8:26   ` Zenghui Yu
2019-11-08 16:57 ` [PATCH v2 04/11] irqchip/gic-v3-its: Make is_v4 use a TYPER copy Marc Zyngier
2019-11-08 16:57 ` [PATCH v2 05/11] irqchip/gic-v3-its: Kill its->ite_size and use TYPER copy instead Marc Zyngier
2019-11-08 16:58 ` [PATCH v2 06/11] irqchip/gic-v3-its: Kill its->device_ids " Marc Zyngier
2019-11-08 16:58 ` [PATCH v2 07/11] irqchip/gic-v3-its: Add its_vlpi_map helpers Marc Zyngier
2019-11-10  0:27   ` kbuild test robot
2019-11-10 14:46   ` Marc Zyngier
2019-11-08 16:58 ` [PATCH v2 08/11] irqchip/gic-v3-its: Synchronise INV command targetting a VLPI using VSYNC Marc Zyngier
2019-11-20 13:21   ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2019-11-08 16:58 ` Marc Zyngier [this message]
2019-11-20 13:21   ` [tip: irq/core] irqchip/gic-v3-its: Synchronise INT/CLEAR commands " tip-bot2 for Marc Zyngier
2019-11-08 16:58 ` [PATCH v2 10/11] irqchip/irq-gic-v3-its: Lock VLPI map array before translating it Marc Zyngier
2019-11-20 13:21   ` [tip: irq/core] irqchip/gic-v3-its: " tip-bot2 for Marc Zyngier
2019-11-08 16:58 ` [PATCH v2 11/11] irqchip/gic-v3-its: Make vlpi_lock a spinlock Marc Zyngier
2019-11-20 13:21   ` [tip: irq/core] " tip-bot2 for Marc Zyngier

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=20191108165805.3071-10-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=Andrew.Murray@arm.com \
    --cc=guoheyi@huawei.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=tglx@linutronix.de \
    --cc=yuzenghui@huawei.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.