From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDwiY-0006Dx-Rz for qemu-devel@nongnu.org; Fri, 17 Jun 2016 12:34:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDwiT-0002sl-Gc for qemu-devel@nongnu.org; Fri, 17 Jun 2016 12:34:02 -0400 Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]:38538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDwiT-0002sc-Af for qemu-devel@nongnu.org; Fri, 17 Jun 2016 12:33:57 -0400 Received: by mail-wm0-x230.google.com with SMTP id m124so6767041wme.1 for ; Fri, 17 Jun 2016 09:33:57 -0700 (PDT) From: =?UTF-8?q?Alex=20Benn=C3=A9e?= Date: Fri, 17 Jun 2016 17:33:40 +0100 Message-Id: <1466181227-14934-1-git-send-email-alex.bennee@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [Qemu-devel] [RFC 0/7] Safe watch and breakpoint manipulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mttcg@listserver.greensocs.com, qemu-devel@nongnu.org, fred.konrad@greensocs.com, a.rigo@virtualopensystems.com, serge.fdrv@gmail.com, cota@braap.org, bobby.prani@gmail.com Cc: mark.burton@greensocs.com, pbonzini@redhat.com, jan.kiszka@siemens.com, rth@twiddle.net, peter.maydell@linaro.org, claudio.fontana@huawei.com, =?UTF-8?q?Alex=20Benn=C3=A9e?= Hi, Last time I went through the MTTCG code the access to the break/watchpoint code was annotated with "RCU?". The code currently gets away with avoiding locks for the gdbstub as the guest execution state is usually halted. However when used for modelling architectural debug registers there is no such protection. The patch series changes things in stages. First we move the break/watchpoints into an array which is more amenable to RCU control that the QLIST. We then control the life time of references to break/watchpoint data by removing long held references in the target code and getting information when needed from the core. Then we stop dynamically allocation the watch/breakpoint data and store it directly in the array which makes iteration across the list a bit more cache friendly than referenced pointers. Finally addition and removal of elements of the array is put under RCU control. This ensures there is always a safe array of data to check in the run-loop. I've taken the decision not to use the RCU like mechanism for setting the hit flags because I can't construct a potential race between a WP being hit and it being removed or updated. I've tested with the gdbstub on ARMv7 using ./tests/guest-debug/test-gdbstub.py and done some manual testing with arm-linux/qemu-arm -g 1234 and everything seems to work fine. I could really do with adding some unit tests for exercising this code but I'm unsure of the best approach of doing this. Cheers, Alex Bennée (7): cpu: move break/watchpoints into arrays. exec: keep CPUWatchpoint references internal exec: keep CPUBreakpoint references internal break/watchpoints: store inside array breakpoints: put breakpoints under RCU control linux-user: don't clone watchpoints watchpoints: put watchpoints under RCU control cpu-exec.c | 7 +- cpus.c | 3 + exec.c | 522 ++++++++++++++++++++++++++++++++++++--------- gdbstub.c | 4 +- include/qom/cpu.h | 160 ++++++++++++-- linux-user/main.c | 13 +- qom/cpu.c | 2 - target-arm/cpu.h | 3 - target-arm/helper.c | 24 +-- target-arm/op_helper.c | 10 +- target-arm/translate-a64.c | 6 +- target-arm/translate.c | 6 +- target-i386/bpt_helper.c | 44 ++-- target-i386/cpu.h | 4 - target-lm32/cpu.h | 3 - target-lm32/helper.c | 31 +-- target-s390x/helper.c | 10 +- target-xtensa/cpu.h | 3 - target-xtensa/helper.c | 4 +- target-xtensa/op_helper.c | 16 +- 20 files changed, 639 insertions(+), 236 deletions(-) -- 2.7.4