Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2443565pxu; Sat, 28 Nov 2020 14:21:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJzVlH8pbEM5OwORQytWr0+LLIvBhsvnz446NdrBw8cF8FQjyCw1NiwOQnD3dbkV3IaDV5fG X-Received: by 2002:a05:6402:948:: with SMTP id h8mr2705795edz.360.1606602086942; Sat, 28 Nov 2020 14:21:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606602086; cv=none; d=google.com; s=arc-20160816; b=MVVDEXcWAFLjRwYziObkDII5PnyY1MHcX2ChD7UWYVeYj/pEpuQiZPgn6zfXueqnpu F9QHdp/ZOA4S3wWVAticDPX77kH59z/Nv7nOHx2N+zji6y5dxYRkFk9dj0VLSk5cpYaN 1PKNsNqqo8OU92wMYtW1rVanb5r0/px9kh3WWRlrD4U/VTUApxA1z45u+gQJKipJ/wJc u38TAscqv91oSEp4bSrSNMk3OGcIye5kzCxOj6x8vnIW+MyHJjKG5j5xJfI0+q1aVl51 GtB6b1vWYfPHGAufpnWpcZOzoopNQQgssiyHgC/HPb368AAzZHGihHpxiM0S8jjcJZLy t2vQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=ZY90qNjYuE6i3HsRLMo8ihyU9b3w8z4NGyX5iK8H36o=; b=nMKVXPeyVWUGlUGbgCfzwRCOYzg/czs+A/O0CC5UYuJ7/ETF5XKDGjgJuySBHP+A4V 2dP+SdqtCCXhDra83pBoejNaCoU6MH5rtD5sPQJ4InVDVC3i7gumidYZJRzDkgWDf7Mb qrk9Nc0Ye846DmENGqPe654lvp3/dBiZaspJPoCgS9Mxp8LH185nb9q/xO+kIj6vEh5j 325/+dboAI3wZTpgI6J3D0Nv0yhSwRr4fuZYm18wJ22RlifJ/vdp5YpdLGKfKD47YOlB vF0UyM3s/JrR3L8ml09Gz67eGs1DW9aajRlxy8dyp0jasqCtQYJYurMjjSe/bX7GJQi0 4ucw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a20si9819849edn.39.2020.11.28.14.21.04; Sat, 28 Nov 2020 14:21:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388817AbgK1Vtp (ORCPT + 99 others); Sat, 28 Nov 2020 16:49:45 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:9066 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732698AbgK1Rzn (ORCPT ); Sat, 28 Nov 2020 12:55:43 -0500 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4CjtsL68GZzLwH9; Sat, 28 Nov 2020 22:19:02 +0800 (CST) Received: from DESKTOP-7FEPK9S.china.huawei.com (10.174.187.74) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.487.0; Sat, 28 Nov 2020 22:19:24 +0800 From: Shenming Lu To: Marc Zyngier , Thomas Gleixner , "Jason Cooper" , , , , , James Morse , Julien Thierry , Suzuki K Poulose , Catalin Marinas , Will Deacon , Eric Auger , Christoffer Dall CC: , , Subject: [PATCH v2 0/2] KVM: arm64: Optimize the wait for the completion of the VPT analysis Date: Sat, 28 Nov 2020 22:18:55 +0800 Message-ID: <20201128141857.983-1-lushenming@huawei.com> X-Mailer: git-send-email 2.27.0.windows.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.174.187.74] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Right after a vPE is made resident, the code starts polling the GICR_VPENDBASER.Dirty bit until it becomes 0, where the delay_us is set to 10. But in our measurement, it takes only hundreds of nanoseconds, or 1~2 microseconds, to finish parsing the VPT in most cases. What's more, we found that the MMIO delay on GICv4.1 system (HiSilicon) is about 10 times higher than that on GICv4.0 system in kvm-unit-tests (the specific data is as follows). | GICv4.1 emulator | GICv4.0 emulator mmio_read_user (ns) | 12811 | 1598 After analysis, this is mainly caused by the 10 delay_us, so it might really hurt performance. To avoid this, we can set the delay_us to 1, which is more appropriate in this situation and universal. Besides, we can delay the execution of the polling, giving the GIC a chance to work in parallel with the CPU on the entry path. Shenming Lu (2): irqchip/gic-v4.1: Reduce the delay time of the poll on the GICR_VPENDBASER.Dirty bit KVM: arm64: Delay the execution of the polling on the GICR_VPENDBASER.Dirty bit arch/arm64/kvm/vgic/vgic-v4.c | 16 ++++++++++++++++ arch/arm64/kvm/vgic/vgic.c | 3 +++ drivers/irqchip/irq-gic-v3-its.c | 18 +++++++++++++----- drivers/irqchip/irq-gic-v4.c | 11 +++++++++++ include/kvm/arm_vgic.h | 3 +++ include/linux/irqchip/arm-gic-v4.h | 4 ++++ 6 files changed, 50 insertions(+), 5 deletions(-) -- 2.23.0