From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1B91C0650F for ; Tue, 30 Jul 2019 12:27:27 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B7B93206E0 for ; Tue, 30 Jul 2019 12:27:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B7B93206E0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:60580 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hsRDy-0006S0-RJ for qemu-devel@archiver.kernel.org; Tue, 30 Jul 2019 08:27:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35195) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hsRCa-0005sc-S6 for qemu-devel@nongnu.org; Tue, 30 Jul 2019 08:26:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hsRCZ-00026H-KY for qemu-devel@nongnu.org; Tue, 30 Jul 2019 08:26:00 -0400 Received: from indium.canonical.com ([91.189.90.7]:60710) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hsRCZ-00025K-Ef for qemu-devel@nongnu.org; Tue, 30 Jul 2019 08:25:59 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.86_2 #2 (Debian)) id 1hsRCU-0006Dg-Lx for ; Tue, 30 Jul 2019 12:25:54 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 8DFCB2E819A for ; Tue, 30 Jul 2019 12:25:51 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jul 2019 12:17:58 -0000 From: Peter Maydell To: qemu-devel@nongnu.org X-Launchpad-Notification-Type: bug X-Launchpad-Bug: product=qemu; status=New; importance=Undecided; assignee=None; X-Launchpad-Bug-Tags: arm tcg X-Launchpad-Bug-Information-Type: Public X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: elouan-appere pmaydell X-Launchpad-Bug-Reporter: =?utf-8?q?Elouan_App=C3=A9r=C3=A9_=28elouan-apper?= =?utf-8?q?e=29?= X-Launchpad-Bug-Modifier: Peter Maydell (pmaydell) References: <156441235921.17753.6613889826588806043.malonedeb@gac.canonical.com> Message-Id: <156448907819.23109.744088068823366380.malone@chaenomeles.canonical.com> X-Launchpad-Message-Rationale: Subscriber (QEMU) @qemu-devel-ml X-Launchpad-Message-For: qemu-devel-ml Precedence: bulk X-Generated-By: Launchpad (canonical.com); Revision="19010"; Instance="launchpad-lazr.conf" X-Launchpad-Hash: fa638bf410bdf09f7fdb5d3982dfab8bbce93944 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 91.189.90.7 Subject: [Qemu-devel] [Bug 1838277] Re: qemu-system-aarch64: regression: TCG sometimes using wrong values for VBAR_EL2 despite it being correctly reported to GDB X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bug 1838277 <1838277@bugs.launchpad.net> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Your example_x20_mov_sp_x8 binary performs an illegal-exception-return because it does an eret from EL2 to EL1 without having set HCR_EL2.RW to 1. That means that the CPU will continue execution from the exception- return "link address" in ELR_EL2 (and remain in EL2). That is 0, because we just loaded it from address +0x1938 in the binary, which is all- zeroes. Attempting to execute from 0x0 in EL2 triggers a prefetch abort which is taken to EL2 at entry point 0x60001200 (which is where we expect to enter given that VBAR_EL2 is 0x60001000 and this is a synchronous exception to the current EL). The earlier "mov sp, x8" seems to have executed as expected and the SP at the 'eret' is 0x60002ff0. This seems to me to be correct execution of a buggy guest binary. Note that if you are trying to debug this via the gdbstub you may be being misled by a bug in our handling of "single step" -- if you single step an instruction and it causes an exception (eg it is a load from a bad address) then instead of stopping execution at the exception-entry- point, we will execute one instruction at the exception-entry-point and then stop after that. So you get back control in gdb one instruction later than you expect. -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1838277 Title: qemu-system-aarch64: regression: TCG sometimes using wrong values for VBAR_EL2 despite it being correctly reported to GDB Status in QEMU: New Bug description: Affects 3.1.0 (latest stable release) and latest commit (893dc8300c80e3dc32f31e968cf7aa0904da50c3) but did *not* affect 2.11 (qemu from bionic ubuntu LTS). With the following code and shell commands: test.s: .text mov x0, #0x60000000 msr vbar_el2, x0 dsb sy isb sy $ aarch64-none-elf-as test.s -o test.o $ aarch64-none-elf-objcopy -S -O binary test.o test.bin $ qemu-system-aarch64 -nographic -machine virt,virtualization=3Don -cpu c= ortex-a57 -kernel test.bin -s -S vbar_el2 is still 0 after the code, instead of being the expected 0x60000000. (see screenshot). This regression doesn't seem to happen for vbar_el1 & virtualization=3Doff. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1838277/+subscriptions