From patchwork Thu Jan 27 12:20:51 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: James Morse X-Patchwork-Id: 12726715 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 35BB4C433F5 for ; Thu, 27 Jan 2022 12:23:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=F6McOQAmYC/zcmWp/JBLxs02lemyH6+ZcWs+PjWGYbE=; b=2sxv4ZvWaTOIlY k3zc1U+t9NDU+8+eyIwNYwq+E/7EN4EzBFQ+JScFs+Xwo0dUeSqBjViCvfuap0K1psNBFqXu1kaV2 /CT5bkxCoQMou5I3sLUsgqN9W+9kOuCCCtCuKdubbKkB/hsBfXGCmV/VHrbnN2HTT3C6J8kyxu2+r gGctZ6ssIeIbhCY1adXWJq5XxPHjLpZD37FoX9yzLd3qPsKUPxhQL9F7DNtSTiwh4+0hcq2+XG/wk /WEsv0n+WYfSmhAOGnK4QSuivztYAlC2eG/jHY/+5QIKOlHbabjdbV/AsvLLCvi/CI8ujTluGGo7p Nhg/Yf1FfZTnoX89hF1Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nD3md-00Fe51-FF; Thu, 27 Jan 2022 12:21:47 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nD3m7-00FduI-7s for linux-arm-kernel@lists.infradead.org; Thu, 27 Jan 2022 12:21:16 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 078E1113E; Thu, 27 Jan 2022 04:21:14 -0800 (PST) Received: from eglon.cambridge.arm.com (unknown [10.1.196.218]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E1A203F7D8; Thu, 27 Jan 2022 04:21:12 -0800 (PST) From: James Morse To: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Cc: Marc Zyngier , Catalin Marinas , Will Deacon , Alexandru Elisei , Suzuki K Poulose , Anshuman Khandual Subject: [PATCH v2 3/4] KVM: arm64: Stop handle_exit() from handling HVC twice when an SError occurs Date: Thu, 27 Jan 2022 12:20:51 +0000 Message-Id: <20220127122052.1584324-4-james.morse@arm.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220127122052.1584324-1-james.morse@arm.com> References: <20220127122052.1584324-1-james.morse@arm.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220127_042115_350709_4BCD291F X-CRM114-Status: GOOD ( 15.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Prior to commit defe21f49bc9 ("KVM: arm64: Move PC rollback on SError to HYP"), when an SError is synchronised due to another exception, KVM handles the SError first. If the guest survives, the instruction that triggered the original exception is re-exectued to handle the first exception. HVC is treated as a special case as the instruction wouldn't normally be re-exectued, as its not a trap. Commit defe21f49bc9 didn't preserve the behaviour of the 'return 1' that skips the rest of handle_exit(). Since commit defe21f49bc9, KVM will try to handle the SError and the original exception at the same time. When the exception was an HVC, fixup_guest_exit() has already rolled back ELR_EL2, meaning if the guest has virtual SError masked, it will execute and handle the HVC twice. Restore the original behaviour. Fixes: defe21f49bc9 ("KVM: arm64: Move PC rollback on SError to HYP") Cc: stable@vger.kernel.org Signed-off-by: James Morse --- It may be possible to remove both this patch, and the HVC handling code in fixup_guest_exit(). This means KVM would always handle the exception and the SError. This may result in unnecessary work if the guest takes the virtual SError when it is next restarted, but should be harmless if SError are always re-injected using HCR_EL2.VSE. --- arch/arm64/kvm/handle_exit.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c index fd2dd26caf91..e3140abd2e2e 100644 --- a/arch/arm64/kvm/handle_exit.c +++ b/arch/arm64/kvm/handle_exit.c @@ -228,6 +228,14 @@ int handle_exit(struct kvm_vcpu *vcpu, int exception_index) { struct kvm_run *run = vcpu->run; + if (ARM_SERROR_PENDING(exception_index)) { + /* + * The SError is handled by handle_exit_early(). If the guest + * survives it will re-execute the original instruction. + */ + return 1; + } + exception_index = ARM_EXCEPTION_CODE(exception_index); switch (exception_index) {