From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkaZm-0007N1-Ow for qemu-devel@nongnu.org; Fri, 09 Oct 2015 12:31:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkaZk-0003v7-12 for qemu-devel@nongnu.org; Fri, 09 Oct 2015 12:31:22 -0400 Received: from mail-lb0-x22c.google.com ([2a00:1450:4010:c04::22c]:33426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkaZj-0003tc-PG for qemu-devel@nongnu.org; Fri, 09 Oct 2015 12:31:19 -0400 Received: by lbos8 with SMTP id s8so85718719lbo.0 for ; Fri, 09 Oct 2015 09:31:19 -0700 (PDT) References: <1443434870-5702-1-git-send-email-serge.fdrv@gmail.com> <1443434870-5702-3-git-send-email-serge.fdrv@gmail.com> <5617C836.8020103@gmail.com> From: Sergey Fedorov Message-ID: <5617EBD4.4060804@gmail.com> Date: Fri, 9 Oct 2015 19:31:16 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 2/2] target-arm: Fix CPU breakpoint handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers On 09.10.2015 17:04, Peter Maydell wrote: > On 9 October 2015 at 14:59, Sergey Fedorov wrote: >> On 08.10.2015 21:40, Peter Maydell wrote: >>> Annoying corner case which I don't think we need to handle necessarily: >>> if you set a breakpoint on a 32-bit Thumb instruction which spans a page >>> boundary, and the second page is not present, we will end up taking the >>> page fault when I think we should take the breakpoint. I can't think >>> of a way to get that right, so just commenting that it isn't handled >>> right would do. >> Could you please point out the piece of code which will generate the >> page fault? Maybe I will give it a thought :) > When you call arm_ldl_code() and friends, they will end up longjmp()ing > out of the codegen phase if the load faults. This then turns into a > guest-visible fault in the usual way. > > To avoid this you'd need to instead call functions which return > a transaction status, but then: > (a) you need to restructure the translate.c code so it can > deal with the idea of backing out if the instruction isn't > actually present > (b) this still wouldn't work for linux-user mode, where we > don't have any way to say "do a memory access, but let me know > if it would fail rather than longjmping" Hm... Seems we will get the page fault instead of the CPU breakpoint not only on a 32-bit Thumb instruction which spans a page boundary but on every instruction translation fetch when the page is not present. Do I understand it correctly? Best regards, Sergey