* Re: [PATCH v2] irqchip/gic-v3-its: Use the exact ITSList for VMOVP
[not found] <1571802386-2680-1-git-send-email-yuzenghui@huawei.com>
@ 2019-10-25 8:24 ` Marc Zyngier
2019-10-25 9:06 ` Zenghui Yu
2019-10-25 12:30 ` [tip: irq/urgent] " tip-bot2 for Zenghui Yu
1 sibling, 1 reply; 3+ messages in thread
From: Marc Zyngier @ 2019-10-25 8:24 UTC (permalink / raw)
To: Zenghui Yu
Cc: tglx, jason, kvmarm, linux-arm-kernel, wanghaibin.wang, jiayanlei, LKML
On 2019-10-23 04:46, Zenghui Yu wrote:
> On a system without Single VMOVP support (say GITS_TYPER.VMOVP == 0),
> we will map vPEs only on ITSs that will actually control interrupts
> for the given VM. And when moving a vPE, the VMOVP command will be
> issued only for those ITSs.
>
> But when issuing VMOVPs we seemed fail to present the exact ITSList
> to ITSs who are actually included in the synchronization operation.
> The its_list_map we're currently using includes all ITSs in the
> system,
> even though some of them don't have the corresponding vPE mapping at
> all.
>
> Introduce get_its_list() to get the per-VM its_list_map, to indicate
> which ITSs have vPE mappings for the given VM, and use this map as
> the expected ITSList when building VMOVP. This is hopefully a
> performance
> gain not to do some synchronization with those unsuspecting ITSs.
> And initialize the whole command descriptor to zero at beginning,
> since
> the seq_num and its_list should be RES0 when GITS_TYPER.VMOVP == 1.
>
> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
I've applied this as a fix for 5.4. In the future, please cc LKML on
all
IRQ-related patches (as documented in MAINTAINERS).
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 3+ messages in thread* [tip: irq/urgent] irqchip/gic-v3-its: Use the exact ITSList for VMOVP
[not found] <1571802386-2680-1-git-send-email-yuzenghui@huawei.com>
2019-10-25 8:24 ` [PATCH v2] irqchip/gic-v3-its: Use the exact ITSList for VMOVP Marc Zyngier
@ 2019-10-25 12:30 ` tip-bot2 for Zenghui Yu
1 sibling, 0 replies; 3+ messages in thread
From: tip-bot2 for Zenghui Yu @ 2019-10-25 12:30 UTC (permalink / raw)
To: linux-tip-commits
Cc: Zenghui Yu, Marc Zyngier, Ingo Molnar, Borislav Petkov, linux-kernel
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: 8424312516e5d9baeeb0a95d0e4523579b7aa395
Gitweb: https://git.kernel.org/tip/8424312516e5d9baeeb0a95d0e4523579b7aa395
Author: Zenghui Yu <yuzenghui@huawei.com>
AuthorDate: Wed, 23 Oct 2019 03:46:26
Committer: Marc Zyngier <maz@kernel.org>
CommitterDate: Thu, 24 Oct 2019 18:02:53 +01:00
irqchip/gic-v3-its: Use the exact ITSList for VMOVP
On a system without Single VMOVP support (say GITS_TYPER.VMOVP == 0),
we will map vPEs only on ITSs that will actually control interrupts
for the given VM. And when moving a vPE, the VMOVP command will be
issued only for those ITSs.
But when issuing VMOVPs we seemed fail to present the exact ITSList
to ITSs who are actually included in the synchronization operation.
The its_list_map we're currently using includes all ITSs in the system,
even though some of them don't have the corresponding vPE mapping at all.
Introduce get_its_list() to get the per-VM its_list_map, to indicate
which ITSs have vPE mappings for the given VM, and use this map as
the expected ITSList when building VMOVP. This is hopefully a performance
gain not to do some synchronization with those unsuspecting ITSs.
And initialize the whole command descriptor to zero at beginning, since
the seq_num and its_list should be RES0 when GITS_TYPER.VMOVP == 1.
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/1571802386-2680-1-git-send-email-yuzenghui@huawei.com
---
drivers/irqchip/irq-gic-v3-its.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 62e54f1..787e8ee 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -175,6 +175,22 @@ static DEFINE_IDA(its_vpeid_ida);
#define gic_data_rdist_rd_base() (gic_data_rdist()->rd_base)
#define gic_data_rdist_vlpi_base() (gic_data_rdist_rd_base() + SZ_128K)
+static u16 get_its_list(struct its_vm *vm)
+{
+ struct its_node *its;
+ unsigned long its_list = 0;
+
+ list_for_each_entry(its, &its_nodes, entry) {
+ if (!its->is_v4)
+ continue;
+
+ if (vm->vlpi_count[its->list_nr])
+ __set_bit(its->list_nr, &its_list);
+ }
+
+ return (u16)its_list;
+}
+
static struct its_collection *dev_event_to_col(struct its_device *its_dev,
u32 event)
{
@@ -976,17 +992,15 @@ static void its_send_vmapp(struct its_node *its,
static void its_send_vmovp(struct its_vpe *vpe)
{
- struct its_cmd_desc desc;
+ struct its_cmd_desc desc = {};
struct its_node *its;
unsigned long flags;
int col_id = vpe->col_idx;
desc.its_vmovp_cmd.vpe = vpe;
- desc.its_vmovp_cmd.its_list = (u16)its_list_map;
if (!its_list_map) {
its = list_first_entry(&its_nodes, struct its_node, entry);
- desc.its_vmovp_cmd.seq_num = 0;
desc.its_vmovp_cmd.col = &its->collections[col_id];
its_send_single_vcommand(its, its_build_vmovp_cmd, &desc);
return;
@@ -1003,6 +1017,7 @@ static void its_send_vmovp(struct its_vpe *vpe)
raw_spin_lock_irqsave(&vmovp_lock, flags);
desc.its_vmovp_cmd.seq_num = vmovp_seq_num++;
+ desc.its_vmovp_cmd.its_list = get_its_list(vpe->its_vm);
/* Emit VMOVPs */
list_for_each_entry(its, &its_nodes, entry) {
^ permalink raw reply [flat|nested] 3+ messages in thread