From nobody Thu Apr 25 19:48:51 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1578679388; cv=none; d=zohomail.com; s=zohoarc; b=VSQG+KKI43QtzeBwtiqOTUZ7D3RPYETqjkHShmccYJHfMo9f1xQ4KJnOYhZP0pjZsNU8fggSkUooqMg7m8HWgSLtVFhMqlW89+KXFGzepdmcEQa02U7VLgbwIsXWMPSbCveGLA8HSMLoqNKujMmN+ywBeIMqOK58g8jHJO22Jko= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1578679388; h=Content-Type:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=kLudMn4JyTZiBhnPslBShyQC8ViDH7jidoKTxFl4ngU=; b=OM4uIAQqyzbig7HN8bErh7BVWPOuwLrm6No87fcDb/ZrlTK1vFHe01J54h0LQU0BncHtoqSDWFNl07M6wFp67KZNz2O8Ht9YVxPnvsXCT+vBXbypmB7qeSGM9G8dgm4ConQ4Ba0eApcqX7Q7XmYIxEeyhVukAM9x7gJO47/VoHk= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 157867938877067.83428254497369; Fri, 10 Jan 2020 10:03:08 -0800 (PST) Received: from localhost ([::1]:50230 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipycl-0008Q4-Dd for importer@patchew.org; Fri, 10 Jan 2020 13:03:07 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51194) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipyc3-0007lz-BD for qemu-devel@nongnu.org; Fri, 10 Jan 2020 13:02:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ipyc2-00062W-8A for qemu-devel@nongnu.org; Fri, 10 Jan 2020 13:02:23 -0500 Received: from mail.dornerworks.com ([12.207.209.150]:34882 helo=webmail.dornerworks.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ipybz-0005iE-Q1; Fri, 10 Jan 2020 13:02:19 -0500 From: Jeff Kubascik To: Peter Maydell , , Subject: [PATCH] target/arm: adjust program counter for wfi exception in AArch32 Date: Fri, 10 Jan 2020 13:02:11 -0500 Message-ID: <20200110180211.29025-1-jeff.kubascik@dornerworks.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 X-Originating-IP: [172.27.13.179] X-ClientProxiedBy: Mcbain.dw.local (172.27.1.45) To Mcbain.dw.local (172.27.1.45) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 12.207.209.150 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Stewart Hildebrand , Jarvis Roach Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The wfi instruction can be configured to be trapped by a higher exception level, such as the EL2 hypervisor. When the instruction is trapped, the program counter should contain the address of the wfi instruction that caused the exception. The program counter is adjusted for this in the wfi op helper function. However, this correction is done to env->pc, which only applies to AArch64 mode. For AArch32, the program counter is stored in env->regs[15]. This adds an if-else statement to modify the correct program counter location based on the the current CPU mode. Signed-off-by: Jeff Kubascik Reviewed-by: Richard Henderson --- Hello, I am using the ARMv8 version of QEMU to run the Xen hypervisor with a guest virtual machine compiled for AArch32/Thumb code. I have noticed that when the AArch32 guest VM executes the wfi instruction, the hypervisor trap of the wfi instruction sees the program counter contain the address of the instruction following the wfi. This does not occur for an AARch64 guest VM; in this case, the program counter contains the address of the wfi instruction. I am confident the correct behavior in both cases is for the program counter to contain the address of the wfi instruction, as this works on actual hardware (Xilinx Zynq UltraScale+ MPSoC). I have tested the above patch and it works for Xen with both an AArch64 guest (Linux) and an AArch32 guest (RTEMS). I'm still getting accustomed to the QEMU code base, so it may not be correct. Any feedback would be greatly appreciated. Sincerely, Jeff Kubascik --- target/arm/op_helper.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/target/arm/op_helper.c b/target/arm/op_helper.c index e5a346cb87..7295645854 100644 --- a/target/arm/op_helper.c +++ b/target/arm/op_helper.c @@ -295,7 +295,11 @@ void HELPER(wfi)(CPUARMState *env, uint32_t insn_len) } =20 if (target_el) { - env->pc -=3D insn_len; + if (env->aarch64) + env->pc -=3D insn_len; + else + env->regs[15] -=3D insn_len; + raise_exception(env, EXCP_UDEF, syn_wfx(1, 0xe, 0, insn_len =3D=3D= 2), target_el); } --=20 2.17.1