Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp240864ybg; Sun, 31 May 2020 23:28:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwpfz/v4iLFd5IBVbX/iA6hMZ6o1LcGcCW1wjpTA8fagS2yFb/nojZTNyEiYiHR7OF5SpGn X-Received: by 2002:a05:6402:1d82:: with SMTP id dk2mr18240497edb.75.1590992918871; Sun, 31 May 2020 23:28:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590992918; cv=none; d=google.com; s=arc-20160816; b=JlDWyHYGx5fvAQ4VjvuBgzZ6UtVFsmufic57Yw4Uu4B9k+EHIiOxkK1WMQSlbE0f1b w0YS49S3vtuN23kxPHQlQOOw28m2PuXsfMgArtJgS7mhGg42X6cjLLmEMG75Nh6Mi7oC 2dEs+hkbdUFPzom2F77vFHbh+W87IGr0JxOg+WqNstcePRkKbYAWdeIjGhXIZK2mYAm0 PTOCdGvjRRHwGJd5TcTjOUbw0c1BX5K4tiRz4PRMF2A8YSfjZ55NCDIi6PJog3QrNYLk SZdhL763T3OtyEwEtRtTT1LAZOBR4OGK7OpRkj4gC1J7LVrx+Kr6CbJmzm/U6Gf/EEd1 YTYQ== 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:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=jEcbDgn0boWZx+zPfn/C6qCoU53nAP+mQQM8vnqq0AY=; b=ydSR2z3CRkmutoKQuFd6TPz7ySkiodPz+/BC+RxTouyi63Y0cn+Nu02HDSMh61HLaL 5gmQkdf8OHsVsPyeilVGbHK8W5L1IH5hF+LPcghys81TJGEnVyMh9trT/x9BV17yxk/s YuQb/GOuloktk26alyFdLBT6o+cQZuPRCz5hY8RLcaLJSzk+OofCokm5yhp3DFIMlnbc bWREB66eSIL9JRzMleouhCB9yyQfgfoDB155ZdWhVlsRoYagge0VkYS1UhnND6LPQTp7 pE1/eyQ2uA7BOGRCf20SjZ3J2djixxegFqbQzDXJXXLxtx3nG6XumPyJ3QSGssHt41/1 Y5fQ== 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 v5si5345770eji.39.2020.05.31.23.28.15; Sun, 31 May 2020 23:28:38 -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 S1726070AbgFAG00 (ORCPT + 99 others); Mon, 1 Jun 2020 02:26:26 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:5315 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725946AbgFAG0Z (ORCPT ); Mon, 1 Jun 2020 02:26:25 -0400 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 8D7BD5F8F2CAC077568D; Mon, 1 Jun 2020 14:26:22 +0800 (CST) Received: from [10.173.221.230] (10.173.221.230) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.487.0; Mon, 1 Jun 2020 14:26:15 +0800 Subject: Re: [PATCH RFC] KVM: arm64: Sidestep stage2_unmap_vm() on vcpu reset when S2FWB is supported To: Marc Zyngier , Alexandru Elisei References: <20200415072835.1164-1-yuzenghui@huawei.com> <13db879dff56d091f98f7c5416ab1535@kernel.org> CC: Zenghui Yu , , , From: zhukeqian Message-ID: Date: Mon, 1 Jun 2020 14:26:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <13db879dff56d091f98f7c5416ab1535@kernel.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.221.230] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, On 2020/5/31 0:31, Marc Zyngier wrote: > Hi Alex, > > On 2020-05-30 11:46, Alexandru Elisei wrote: >> Hi, > > [...] > >>>> 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)) >>> I think userspace does not invalidate the icache when loading a new kernel image, >>> and if the guest patched instructions, they could potentially still be in the >>> icache. Should the icache be invalidated if FWB is present? >> >> I noticed that this was included in the current pull request and I >> remembered that >> I wasn't sure about this part. Did some more digging and it turns out that FWB >> implies no cache maintenance needed for *data to instruction* >> coherence. From ARM >> DDI 0487F.b, page D5-2635: >> >> "When ARMv8.4-S2FWB is implemented, the architecture requires that >> CLIDR_EL1.{LOUU, LOIUS} are zero so that no levels of data cache need to be >> cleaned in order to manage coherency with instruction fetches". >> >> However, there's no mention that I found for instruction to data coherence, >> meaning that the icache would still need to be invalidated on each vcpu in order >> to prevent fetching of patched instructions from the icache. Am I >> missing something? > > I think you are right, and this definitely matches the way we deal with > the icache on the fault path. For some bizarre reason, I always assume > that FWB implies DIC, which isn't true at all. > > I'm planning to address it as follows. Please let me know what you think. > > Thanks, > > M. > > From f7860d1d284f41afea176cc17e5c9d895ae665e9 Mon Sep 17 00:00:00 2001 > From: Marc Zyngier > Date: Sat, 30 May 2020 17:22:19 +0100 > Subject: [PATCH] KVM: arm64: Flush the instruction cache if not unmapping the > VM on reboot > > On a system with FWB, we don't need to unmap Stage-2 on reboot, > as even if userspace takes this opportunity to repaint the whole > of memory, FWB ensures that the data side stays consistent even > if the guest uses non-cacheable mappings. > > However, the I-side is not necessarily coherent with the D-side > if CTR_EL0.DIC is 0. In this case, invalidate the i-cache to > preserve coherency. > > Reported-by: Alexandru Elisei > Fixes: 892713e97ca1 ("KVM: arm64: Sidestep stage2_unmap_vm() on vcpu reset when S2FWB is supported") > Signed-off-by: Marc Zyngier > --- > arch/arm64/kvm/arm.c | 14 ++++++++++---- > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index b0b569f2cdd0..d6988401c22a 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -989,11 +989,17 @@ 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. > + * S2FWB enforces all memory accesses to RAM being cacheable, > + * ensuring that the data side is always coherent. We still > + * need to invalidate the I-cache though, as FWB does *not* > + * imply CTR_EL0.DIC. > */ > - if (vcpu->arch.has_run_once && !cpus_have_const_cap(ARM64_HAS_STAGE2_FWB)) > - stage2_unmap_vm(vcpu->kvm); > + if (vcpu->arch.has_run_once) { > + if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB)) > + stage2_unmap_vm(vcpu->kvm); > + else > + __flush_icache_all(); After I looking into this function, I think it's OK here. Please ignore my question :-). > + } > > vcpu_reset_hcr(vcpu); > Thanks, Keqian