From patchwork Mon Feb 26 08:20:04 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Shi X-Patchwork-Id: 10241545 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 9326B60386 for ; Mon, 26 Feb 2018 08:31:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 803B529AD5 for ; Mon, 26 Feb 2018 08:31:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 73CCA29B10; Mon, 26 Feb 2018 08:31:58 +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=unavailable 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 0AB0029AD5 for ; Mon, 26 Feb 2018 08:31:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752240AbeBZIYr (ORCPT ); Mon, 26 Feb 2018 03:24:47 -0500 Received: from mail-pg0-f68.google.com ([74.125.83.68]:43826 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751977AbeBZIYn (ORCPT ); Mon, 26 Feb 2018 03:24:43 -0500 Received: by mail-pg0-f68.google.com with SMTP id e9so1582493pgs.10 for ; Mon, 26 Feb 2018 00:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:subject:date:message-id:in-reply-to:references; bh=/nksGLZqHQjfpQbfH68HEgt65Nc6WZIfEk50r4t0UeE=; b=aJOtU3BbNimU/2ivLtPtjHbi4kjfA18KzNfLloYw4Q3hTZ1P/nyrFFdoe2RaFJ0yNF MdjSu08eySO3EW1vYNOzrRndv6SeEddJWe2AJ7y1/1vb6nXbxJlesLdRWkyFmdB2lNBZ nCwEwHEQ99xu4KOJq6VQKGWXTk6FtFMwzXSS0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=/nksGLZqHQjfpQbfH68HEgt65Nc6WZIfEk50r4t0UeE=; b=IF11MS87hm7CyXJfDzKKCBw62/HpiIBOLf9lsIHVr+J6OF5Yh/4181f/RU83zSqvt7 Zflw1md2oZm+3mB6NKEzGWBeMsXuyRuOX7SOOHY8ETGqy6p/11HDzNZQQOH3r0E9REET dLdp/TsAPukC2lKOEk4voxC+eb4OjCSUF6673qGsTKhY1VDQrUWfolahCaSYWt39/uMb bYMkfmCVtGdOuvnm1IPIkiSu+siA9A1gybTk21FC+EnhXOYGxd7l3idqlBA4bqdGZNgm pO0k0jaeEEvgfbbkgP8LtuzrS8Ea33J7/rZ2Yc/LNKka0EX8d+EAoELlO8w7PtOpfOxq B/wA== X-Gm-Message-State: APf1xPBAwKOeacDlVR42cNtG0nVEv7fNDjhFKu1fP17ZYbJ7N0E94Pf4 1D0fns/RUtMa/MnbrrfOxodYOHztmlk= X-Google-Smtp-Source: AH8x224sXf07/1UaovxeoGYvKB4N4ak2vjiwygI8UCwWpZ58MGgB9BdV/E0oV8AEgRnphKGvX23Haw== X-Received: by 10.99.145.194 with SMTP id l185mr7597844pge.394.1519633483193; Mon, 26 Feb 2018 00:24:43 -0800 (PST) Received: from localhost.localdomain (176.122.172.82.16clouds.com. [176.122.172.82]) by smtp.gmail.com with ESMTPSA id o86sm1422706pfi.87.2018.02.26.00.24.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Feb 2018 00:24:42 -0800 (PST) From: Alex Shi To: Marc Zyngier , Will Deacon , Ard Biesheuvel , Catalin Marinas , stable@vger.kernel.org, Paolo Bonzini , =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= , Christoffer Dall , kvm@vger.kernel.org (open list:KERNEL VIRTUAL MACHINE (KVM)), linux-arm-kernel@lists.infradead.org (moderated list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)), kvmarm@lists.cs.columbia.edu (open list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)), linux-kernel@vger.kernel.org (open list) Subject: [PATCH 30/52] arm64: KVM: Increment PC after handling an SMC trap Date: Mon, 26 Feb 2018 16:20:04 +0800 Message-Id: <1519633227-29832-31-git-send-email-alex.shi@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1519633227-29832-1-git-send-email-alex.shi@linaro.org> References: <1519633227-29832-1-git-send-email-alex.shi@linaro.org> Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Marc Zyngier commit f5115e8869e1 upstream. When handling an SMC trap, the "preferred return address" is set to that of the SMC, and not the next PC (which is a departure from the behaviour of an SMC that isn't trapped). Increment PC in the handler, as the guest is otherwise forever stuck... Cc: stable@vger.kernel.org Fixes: acfb3b883f6d ("arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls") Reviewed-by: Christoffer Dall Tested-by: Ard Biesheuvel Signed-off-by: Marc Zyngier Signed-off-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Alex Shi --- arch/arm64/kvm/handle_exit.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c index 2e6e9e9..5b56b09 100644 --- a/arch/arm64/kvm/handle_exit.c +++ b/arch/arm64/kvm/handle_exit.c @@ -53,7 +53,16 @@ static int handle_hvc(struct kvm_vcpu *vcpu, struct kvm_run *run) static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run) { + /* + * "If an SMC instruction executed at Non-secure EL1 is + * trapped to EL2 because HCR_EL2.TSC is 1, the exception is a + * Trap exception, not a Secure Monitor Call exception [...]" + * + * We need to advance the PC after the trap, as it would + * otherwise return to the same address... + */ vcpu_set_reg(vcpu, 0, ~0UL); + kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu)); return 1; }