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: 10087291 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 BF49F6035E for ; Fri, 1 Dec 2017 15:21:38 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B7BCC2A5DB for ; Fri, 1 Dec 2017 15:21:38 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id AC55D2A5E0; Fri, 1 Dec 2017 15:21:38 +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=-4.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 2043F2A5DB for ; Fri, 1 Dec 2017 15:21:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XItN/TPZLKZXivqJRIcySHJPG9w808igknQumQPFG5Q=; b=f0gpy+jxWu6g1U bqoC6m4+PNVZcpy0Ayc25KRWQ4bqC5GW/hEnW6inpFpD09qXXHKthGpvF4j4mTH9kTBP4eNWzPY0r fvfOusx3ugYFmAPmascmuopOG1lig8+E+ZJmUns9d+Yw35a+iLp+40isZ0Y5dANmBYj361GKI2yQy XZjt7LkYPDOZR9Msy3jNlVjwK/mNnN7tQTpP/0vKEZkUFJzxSJlIlR1MjwNUQjevbOgNbL3hUa1/Y 8zXt4nosE7TbrEqWuJPcUT/1bb40FSodSQV0JUhevbrYh9NvystpmQBRdVSFIFUw9ZzBLnV2rb0P0 gsMPnFsz9nftr+BOGH3g==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1eKn8C-0006Im-6j; Fri, 01 Dec 2017 15:21:36 +0000 Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1eKn6r-0003lX-Rh for linux-arm-kernel@lists.infradead.org; Fri, 01 Dec 2017 15:20:17 +0000 Received: by mail-wm0-x242.google.com with SMTP id r78so4137953wme.5 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=WlW/6v1Y9KGNR4l+b0fttUcFzFRSNRl7dU/v23wVlOaRubNk26uLKtaiZShnp31FNw 4M3sqFOJx5Ut5phjXaCsv8h6UCEKGxAhEv+2fenHMPeso3n3Fu32cfhnVFj8nF86MXVy eRiblrl8Yy9xha62mYuKO3BflHYJxvQMhiKypL4g9VMObeHTd90Bg+MMUkZlLmgv0t1P ZL0TXlxezmkwiIPZZ3GKg6o2+UlEbb7zXN9ElaEiEaqVix3rUJvHEN+95aFavbU/4ZXM erjiaOBrv2nWfXR+dtjAaHMcRbPpPlMtD4Xy2O6XERN9/l9TeuIc2WSMqam2F2R8ifU4 U08w== X-Gm-Message-State: AKGB3mIu0v6XZEqhgmOW5bFKeYoxuLG6XIXvUzuBj5cXHsuhATr24C6a UgNFOUF2wcwUit687GYjm+SK2A== 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 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) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20171201_072014_167975_0307F5A7 X-CRM114-Status: GOOD ( 25.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, Marc Zyngier , Christoffer Dall , Shih-Wei Li , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.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,