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 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 CE9EEC34049 for ; Tue, 18 Feb 2020 20:17:13 +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 A5ED82176D for ; Tue, 18 Feb 2020 20:17:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5ED82176D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bugs.launchpad.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:41516 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j49Iu-0007TV-N8 for qemu-devel@archiver.kernel.org; Tue, 18 Feb 2020 15:17:12 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60934) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j49Hn-0006tK-Ei for qemu-devel@nongnu.org; Tue, 18 Feb 2020 15:16:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j49Hf-000478-2W for qemu-devel@nongnu.org; Tue, 18 Feb 2020 15:15:57 -0500 Received: from indium.canonical.com ([91.189.90.7]:60262) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j49Hb-0003zD-1J for qemu-devel@nongnu.org; Tue, 18 Feb 2020 15:15:51 -0500 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.86_2 #2 (Debian)) id 1j49HY-0001ko-9z for ; Tue, 18 Feb 2020 20:15:48 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 2A71A2E804A for ; Tue, 18 Feb 2020 20:15:48 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Feb 2020 20:06:26 -0000 From: Julien Freche <1863685@bugs.launchpad.net> To: qemu-devel@nongnu.org X-Launchpad-Notification-Type: bug X-Launchpad-Bug: product=qemu; status=In Progress; importance=Undecided; assignee=rth@twiddle.net; X-Launchpad-Bug-Information-Type: Public X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: jfreche rth X-Launchpad-Bug-Reporter: Julien Freche (jfreche) X-Launchpad-Bug-Modifier: Julien Freche (jfreche) References: <158198492915.29307.8701397558481624318.malonedeb@chaenomeles.canonical.com> Message-Id: <158205638674.15520.7270325861172662720.malone@soybean.canonical.com> Subject: [Bug 1863685] Re: ARM: HCR.TSW traps are not implemented 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="19413b719a8df7423ab1390528edadce9e0e4aca"; Instance="production-secrets-lazr.conf" X-Launchpad-Hash: 83798c8216a53263fc1f116d357233a37235e298 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 91.189.90.7 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 1863685 <1863685@bugs.launchpad.net> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Thanks for the quick turn around! I tested both your patches together (it's useful to have both to emulate set/way flushing inside a guest) and I am getting something unexpected. At some point, we are trapping on an access to DACR but ESR_EL2 doesn't seem to make a lot of sense: 0xfe00dc0. I am running a 32-bit Linux inside a VM. Decoding it: Rt is set to 0xe which is LR_usr. Also, this is a read operation. So, essentially the guest seems to try to set DACR to LR_usr which seems unreasonable. It could be an issue with the hypervisor on my side (I am running some custom code). But, it's not obvious to me and the code behaves fine on bare-metal. Is there a chance that ESR is not populated correctly? In any case, I do see traps for set/way instructions so, from that point of view, the patch is good. -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1863685 Title: ARM: HCR.TSW traps are not implemented Status in QEMU: In Progress Bug description: On 32-bit and 64-bit ARM platforms, setting HCR.TSW is supposed to "Trap data or unified cache maintenance instructions that operate by Set/Way." Quoting the ARM manual: If EL1 is using AArch64 state, accesses to DC ISW, DC CSW, DC CISW are tr= apped to EL2, reported using EC syndrome value 0x18. If EL1 is using AArch32 state, accesses to DCISW, DCCSW, DCCISW are trapp= ed to EL2, reported using EC syndrome value 0x03. However, QEMU does not trap those instructions/registers. This was tested on the branch master of the git repo. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1863685/+subscriptions