From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54609) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zka0o-0004XR-Mw for qemu-devel@nongnu.org; Fri, 09 Oct 2015 11:55:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zka0k-0000TU-55 for qemu-devel@nongnu.org; Fri, 09 Oct 2015 11:55:14 -0400 Received: from mail-lb0-x231.google.com ([2a00:1450:4010:c04::231]:33545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zka0j-0000Pc-DF for qemu-devel@nongnu.org; Fri, 09 Oct 2015 11:55:09 -0400 Received: by lbos8 with SMTP id s8so84654905lbo.0 for ; Fri, 09 Oct 2015 08:55:08 -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: <5617E35A.2030800@gmail.com> Date: Fri, 9 Oct 2015 18:55:06 +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" Thank you for the explanation, Peter. I see, if we do insn translation then we take the page fault instead of the CPU breakpoint. As of user mode, can we actually set any CPU breakpoint? If not, as I guess, then (b) is not applicable to the possible solution that you have described. Best regards, Sergey