Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp623649ybz; Wed, 15 Apr 2020 15:21:12 -0700 (PDT) X-Google-Smtp-Source: APiQypL6fiBQG5fIKmJgXtinXCo54BkoY5UtKI7dWxbyuAWQlwXfMyRY3ebLHE1+vPljYmKEW9wp X-Received: by 2002:a17:906:4048:: with SMTP id y8mr7102463ejj.258.1586989272509; Wed, 15 Apr 2020 15:21:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586989272; cv=none; d=google.com; s=arc-20160816; b=L/xrjz+coV152gIPXlrnF7uXYyo2hXWMCIcTZXZU6JAeo9JrKIPF2VN6tqMkOwt1mU X89qi6QrxduZeWWUfxDe4SAFR4FJI+KPSXrNQv1CSGWTnaFgQcGXQjuiNeEBgk3/JtCw li+yIWTICG7UlLMPpe+ux8gU7caCVchevHIeN/fJstUbZuC5Rlv9xI3ZqnP/qgp81OhQ nfs9QQ8Mb/mxsI5gYzKTjLAQFqnm5JkpnrPzH8MIGk4yj/cMcVa/rgMdJFk/GIjlnkLZ 3WT1S31vzvA2jjc4y+rK7XLiBAfCjMWPtZd0dwyQkw2ewM8vZH8GZxXZjJ8a827gd/63 cBlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=yDpYImANa5opm5CcFCkqeTRfdS4OOk6Ni8CAW7Chl4g=; b=tLttmRFdiNckL0QV5D1B4Xl/5UoEPYQ4vYvK2hCn+iKBgKSVr6d+mpt0HsGZapfp/k /YD/zXVHKQiFuRHyGp5lryPpSq6qCzbHka6c0ejRvHoLZ/7y6WhOUxo0RPqWuUIg9/Hf 6wNQgdhiHenDqJ1mcSdw+zeN8v3swGNg+3er7cqckzX3HqSoo9iBsqeXlBj35cl5Hw+Y kCEK11BE/WT9vy8q9RokI0gUPRBt6GQG0mUmgdBVMcoyJVFABDQsTXqap3VUfO4dmXY+ 4l9myQmh4uDzZLem8U+4i8OViRc82kRrFkkSnrVI/EVFiLebJOt4iWF6zbpLcYqTUTH7 DJ4Q== 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 z5si12801261edp.102.2020.04.15.15.20.49; Wed, 15 Apr 2020 15:21:12 -0700 (PDT) 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 S2635273AbgDOHpB (ORCPT + 99 others); Wed, 15 Apr 2020 03:45:01 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:2374 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2635166AbgDOHo5 (ORCPT ); Wed, 15 Apr 2020 03:44:57 -0400 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 2FA05A3C4D514F23AA5D; Wed, 15 Apr 2020 15:29:14 +0800 (CST) Received: from DESKTOP-8RFUVS3.china.huawei.com (10.173.222.27) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.487.0; Wed, 15 Apr 2020 15:29:08 +0800 From: Zenghui Yu To: , , CC: , Zenghui Yu , "Marc Zyngier" , Christoffer Dall , "James Morse" , Julien Thierry , Suzuki K Poulose Subject: [PATCH RFC] KVM: arm64: Sidestep stage2_unmap_vm() on vcpu reset when S2FWB is supported Date: Wed, 15 Apr 2020 15:28:35 +0800 Message-ID: <20200415072835.1164-1-yuzenghui@huawei.com> X-Mailer: git-send-email 2.23.0.windows.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.173.222.27] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org stage2_unmap_vm() was introduced to unmap user RAM region in the stage2 page table to make the caches coherent. E.g., a guest reboot with stage1 MMU disabled will access memory using non-cacheable attributes. If the RAM and caches are not coherent at this stage, some evicted dirty cache line may go and corrupt guest data in RAM. Since ARMv8.4, S2FWB feature is mandatory and KVM will take advantage of it to configure the stage2 page table and the attributes of memory access. So we ensure that guests always access memory using cacheable attributes and thus, the caches always be coherent. So on CPUs that support S2FWB, we can safely reset the vcpu without a heavy stage2 unmapping. Cc: Marc Zyngier Cc: Christoffer Dall Cc: James Morse Cc: Julien Thierry Cc: Suzuki K Poulose Signed-off-by: Zenghui Yu --- If this is correct, there should be a great performance improvement on a guest reboot (or reset) on systems support S2FWB. But I'm afraid that I've missed some points here, so please comment! The commit 957db105c997 ("arm/arm64: KVM: Introduce stage2_unmap_vm") was merged about six years ago and I failed to track its histroy and intention. Instead of a whole stage2 unmapping, something like stage2_flush_vm() looks enough to me. But again, I'm unsure... Thanks for having a look! virt/kvm/arm/arm.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c index 48d0ec44ad77..e6378162cdef 100644 --- a/virt/kvm/arm/arm.c +++ b/virt/kvm/arm/arm.c @@ -983,8 +983,11 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu, /* * Ensure a rebooted VM will fault in RAM pages and detect if the * guest MMU is turned off and flush the caches as needed. + * + * S2FWB enforces all memory accesses to RAM being cacheable, we + * ensure that the cache is always coherent. */ - if (vcpu->arch.has_run_once) + if (vcpu->arch.has_run_once && !cpus_have_const_cap(ARM64_HAS_STAGE2_FWB)) stage2_unmap_vm(vcpu->kvm); vcpu_reset_hcr(vcpu); -- 2.19.1