From patchwork Fri Dec 1 15:19:38 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoffer Dall X-Patchwork-Id: 10087283 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id E014E6035E for ; Fri, 1 Dec 2017 15:19:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D98562A3DE for ; Fri, 1 Dec 2017 15:19:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CDC722A5AA; Fri, 1 Dec 2017 15:19:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F26562A536 for ; Fri, 1 Dec 2017 15:19:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752634AbdLAPTx (ORCPT ); Fri, 1 Dec 2017 10:19:53 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:44311 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751031AbdLAPTw (ORCPT ); Fri, 1 Dec 2017 10:19:52 -0500 Received: by mail-wm0-f68.google.com with SMTP id t8so4130263wmc.3 for ; Fri, 01 Dec 2017 07:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=T/ggK0rSP8+z14fc9NwNxpWsLGb8Rz2kL+LJIyAhBms=; b=WjLDlj7jFUJrSAze0XYqRW0hHYNxBwUZMQpGVkWpZOKfFrpfnsXcYMVpaE7WPx932S sEJfN4RHn+wdIRG6Y9lYJdV1Eoa6ZoiDmzLn33oxL21vbDqRk0QVv9hY8N7mPU9Ym+UC aU/AkuSDAA3aleD6j+36qE3B9KHtVxienCSbU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=T/ggK0rSP8+z14fc9NwNxpWsLGb8Rz2kL+LJIyAhBms=; b=JNaPID0NZ4YNoteyRAOapEcioU3jouE+nJ7nJGR5HXTGpiCHBTWLwXpZA1DwF03/Lg Q6KmqMt9MgDQ0WfVkZhnitruX4+6wVBHUyCapmk5i6lpfEA5Y4yQSWrsL90l0gOigV9q CF39z6MMlrA/NHEu5jjlUzvq6Dgf9BdID+IQ4LtiWHtNYDZbtMwMKx5vJbZ2Xvux24Of rR30Ju8cIRhDl9+B6yyHeZe4mt9n5egZLFqtxgk3XLv68C+6fj5GcGY41/liPJGvFAU7 dNZgLm7uO+9c2GcBDSxfA50+iAccOTXMgRlKcXbqd1r/xPN4uH7egqehXc7/dnLJTV59 Xm/A== X-Gm-Message-State: AKGB3mIVkEpskTlv/hb9RSq+9ko5ZFVuKsMTQeyTJcrGsTnw7JVeKKN8 iHUTHmVlEhmbAWRz9SAzU2+Jag== X-Google-Smtp-Source: AGs4zMbNR2QY9nKUQ+pbrGEpc65CvxUxmW/pIQYtUEjW/AWKgobk04OfRLePApTat+bovLwkCKKvIA== X-Received: by 10.28.108.11 with SMTP id h11mr1502337wmc.28.1512141591448; Fri, 01 Dec 2017 07:19:51 -0800 (PST) Received: from localhost ([128.65.80.151]) by smtp.gmail.com with ESMTPSA id v195sm1260355wmf.25.2017.12.01.07.19.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 07:19:50 -0800 (PST) Date: Fri, 1 Dec 2017 16:19:38 +0100 From: Christoffer Dall To: Julien Thierry Cc: Christoffer Dall , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Marc Zyngier , Shih-Wei Li , kvm@vger.kernel.org Subject: Re: [PATCH 10/37] KVM: arm64: Slightly improve debug save/restore functions Message-ID: <20171201151938.GA6615@lvm> References: <20171012104141.26902-1-christoffer.dall@linaro.org> <20171012104141.26902-11-christoffer.dall@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Julien, On Tue, Nov 14, 2017 at 04:42:13PM +0000, Julien Thierry wrote: > On 12/10/17 11:41, Christoffer Dall wrote: > >The debug save/restore functions can be improved by using the has_vhe() > >static key instead of the instruction alternative. Using the static key > >uses the same paradigm as we're going to use elsewhere, it makes the > >code more readable, and it generates slightly better code (no > >stack setups and function calls unless necessary). > > > >We also use a static key on the restore path, because it will be > >marginally faster than loading a value from memory. > > > >Finally, we don't have to conditionally clear the debug dirty flag if > >it's set, we can just clear it. > > > >Signed-off-by: Christoffer Dall > >--- > > arch/arm64/kvm/hyp/debug-sr.c | 22 +++++++++------------- > > 1 file changed, 9 insertions(+), 13 deletions(-) > > > >diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c > >index 0fc0758..a2291b6 100644 > >--- a/arch/arm64/kvm/hyp/debug-sr.c > >+++ b/arch/arm64/kvm/hyp/debug-sr.c > >@@ -75,11 +75,6 @@ > > #define psb_csync() asm volatile("hint #17") > >-static void __hyp_text __debug_save_spe_vhe(u64 *pmscr_el1) > >-{ > >- /* The vcpu can run. but it can't hide. */ > >-} > >- > > static void __hyp_text __debug_save_spe_nvhe(u64 *pmscr_el1) > > { > > u64 reg; > >@@ -109,10 +104,6 @@ static void __hyp_text __debug_save_spe_nvhe(u64 *pmscr_el1) > > dsb(nsh); > > } > >-static hyp_alternate_select(__debug_save_spe, > >- __debug_save_spe_nvhe, __debug_save_spe_vhe, > >- ARM64_HAS_VIRT_HOST_EXTN); > >- > > static void __hyp_text __debug_restore_spe(u64 pmscr_el1) > > { > > if (!pmscr_el1) > >@@ -174,17 +165,22 @@ void __hyp_text __debug_cond_save_host_state(struct kvm_vcpu *vcpu) > > { > > __debug_save_state(vcpu, &vcpu->arch.host_debug_state.regs, > > kern_hyp_va(vcpu->arch.host_cpu_context)); > >- __debug_save_spe()(&vcpu->arch.host_debug_state.pmscr_el1); > >+ > >+ /* Non-VHE: Disable and flush SPE data generation > >+ * VHE: The vcpu can run. but it can't hide. */ > >+ if (!has_vhe()) > >+ __debug_save_spe_nvhe(&vcpu->arch.host_debug_state.pmscr_el1); > > } > > void __hyp_text __debug_cond_restore_host_state(struct kvm_vcpu *vcpu) > > { > >- __debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1); > >+ if (!has_vhe()) > >+ __debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1); > > For consistency, would it be worth naming that function > '__debug_restore_spe_nvhe' ? Yes. > > Also, looking at __debug_save_spe_nvhe, I'm not sure how we guarantee that > we might not end up using stale data during the restore_spe (though, if this > is an issue, it existed before this change). > The save function might exit without setting a value to saved pmscr_el1. > > Basically I'm wondering if the following scenario (in non VHE) is possible > and/or whether it is problematic: > > - save spe > - restore spe > - host starts using spi -> !(PMBLIMITR_EL1 & PMBLIMITR_EL1_E) spi ? > - save spe -> returns early without setting pmscr_el1 > - restore spe with old save instead of doing nothing > I think I see what you mean. Basically you're asking if we need this: I think we do, and I think this is a separate fix. Would you like to write a patch and cc Will and Marc (original author and committer) to fix this? Probably worth a cc stable as well. Thanks, -Christoffer diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c index 4112160..8ab3510 100644 --- a/arch/arm64/kvm/hyp/debug-sr.c +++ b/arch/arm64/kvm/hyp/debug-sr.c @@ -106,7 +106,7 @@ static void __hyp_text __debug_save_spe_nvhe(u64 *pmscr_el1) static void __hyp_text __debug_restore_spe_nvhe(u64 &pmscr_el1) { - if (!pmscr_el1) + if (*pmscr_el1 != 0) return; /* The host page table is installed, but not yet synchronised */ @@ -114,6 +114,7 @@ static void __hyp_text __debug_restore_spe_nvhe(u64 &pmscr_el1) /* Re-enable data generation */ write_sysreg_s(pmscr_el1, PMSCR_EL1); + *pmscr_el1 = 0; } void __hyp_text __debug_save_state(struct kvm_vcpu *vcpu,