Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp544858imu; Wed, 23 Jan 2019 01:02:35 -0800 (PST) X-Google-Smtp-Source: ALg8bN7ZTjCu3MH1xkShKqEeJkhBkpVlMevWYKqvLHG+8ZPrl3smqAmtdNRhJC8nhxh4bEXLlj4/ X-Received: by 2002:a17:902:b83:: with SMTP id 3mr1376657plr.42.1548234154969; Wed, 23 Jan 2019 01:02:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548234154; cv=none; d=google.com; s=arc-20160816; b=NC29Dd9oj4niHp4dI4CwOXTpRQ/0xhI1U4b0ingOKu4sMBL5p0OJv3qtGEa2UyKvwF Im+OydV2e1y4WV+7JEz4u3WnETjaKhsX/LO+MiNoQhQIdybtHw74ck2tzFPszC6ZQWBm EUgGokxTuJDUR4TxIdN7/EyV9zTiSlh+8RSAoNCLO0+F7HlAQVkV1nh6bZavtDDick6p ss48jSBx/MrUwgl9mznetAbj495pu8lvlT7o9ZW4KZLI+KbsYIZYoYp6E6x5aZuTsDf3 WABqJHCd1IMnXWRl+I8j9KJcYkNEXqnUz2OZXqIxGcYxuc7ekRXem/e9208S1gGwC0lO j62A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=HvJNWiq03HS2+AxDvtAeTseoRu+icWnoDBKwzAQ6SOY=; b=GXS7JdKxHRJZGCAhYDde4rKPBDG1ZYnnxvmyZcY0hFJoMcKVBV5dKsIc0vzmP2FbGd 39ZF3RSegD/s2FfTyz1vuSBY0ByJcTGZa8MyUMs7CiYOhaANedonySUcJIzmOs9Bo+JT Oc6hTcZvmim20vQBoQtpyMN9HtMd3wj8UzBjnYnuYYVIe3ebvxqDxu+bf16+/M77ZjnK 1v0ZNhvJpos4e0T44uNO0hBNS7h52VlEASUndG5fMwYf+tKGL0FKZejouJvvg0QVcWPc ROzmR3jEf5IXevb1aiiV0ZHrezs9aDE65ITrIYUdRCh65KeKGrWXF9iATX3wRq2IJkZ4 0SBQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r18si706981pgu.552.2019.01.23.01.02.19; Wed, 23 Jan 2019 01:02:34 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727113AbfAWJAX (ORCPT + 99 others); Wed, 23 Jan 2019 04:00:23 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:42584 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726207AbfAWJAX (ORCPT ); Wed, 23 Jan 2019 04:00:23 -0500 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 42158B0B4B805E195329; Wed, 23 Jan 2019 17:00:21 +0800 (CST) Received: from linux-fhAnjn.huawei.com (10.175.104.222) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.408.0; Wed, 23 Jan 2019 17:00:14 +0800 From: Heyi Guo To: CC: Thomas Gleixner , Jason Cooper , Marc Zyngier , , Subject: [PATCH] irqchip/gic-v4: fix occasional VLPI drop Date: Wed, 23 Jan 2019 16:59:08 +0800 Message-ID: <1548233948-7450-1-git-send-email-guoheyi@huawei.com> X-Mailer: git-send-email 1.8.3.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.104.222] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 1. In current implementation, every VLPI will temporarily be mapped to the first CPU in system (normally CPU0) and then moved to the real scheduled CPU later. 2. So there is a time window and a VLPI may be sent to CPU0 instead of the real scheduled vCPU, in a multi-CPU virtual machine. 3. However, CPU0 may have not been scheduled as a virtual CPU after system boots up, so the value of its GICR_VPROPBASER is unknown at that moment. 4. If the INTID of VLPI is larger than 2^(GICR_VPROPBASER.IDbits+1), while IDbits is also in unknown state, GIC will behave as if the VLPI is out of range and simply drop it, which results in interrupt missing in Guest. As no code will clear GICR_VPROPBASER at runtime, we can safely initialize the IDbits field at boot time for each CPU to get rid of this issue. We also clear Valid bit of GICR_VPENDBASER in case any ancient programming gets left in and causes memory corrupting. Signed-off-by: Heyi Guo Signed-off-by: Heyi Guo --- drivers/irqchip/irq-gic-v3-its.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 3365d44..634c8a7 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -2145,6 +2145,31 @@ static void its_cpu_init_lpis(void) val |= GICR_CTLR_ENABLE_LPIS; writel_relaxed(val, rbase + GICR_CTLR); + if (gic_rdists->has_vlpis) { + void __iomem *vlpi_base = gic_data_rdist_vlpi_base(); + + /* + * It's possible for CPU to receive VLPIs before it is + * sheduled as a vPE, especially for the first CPU, and the + * VLPI with INTID larger than 2^(IDbits+1) will be considered + * as out of range and dropped by GIC. + * So we initialize IDbits to known value to avoid VLPI drop. + */ + val = (LPI_NRBITS - 1) & GICR_VPROPBASER_IDBITS_MASK; + pr_debug("GICv4: CPU%d: Init IDbits to 0x%llx for GICR_VPROPBASER\n", + smp_processor_id(), val); + gits_write_vpropbaser(val, vlpi_base + GICR_VPROPBASER); + + /* + * Also clear Valid bit of GICR_VPENDBASER, in case some + * ancient programming gets left in and has possibility of + * corrupting memory. + */ + val = gits_read_vpendbaser(vlpi_base + GICR_VPENDBASER); + val &= ~GICR_VPENDBASER_Valid; + gits_write_vpendbaser(val, vlpi_base + GICR_VPENDBASER); + } + /* Make sure the GIC has seen the above */ dsb(sy); out: -- 1.8.3.1