From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58279) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgU56-0004xJ-RG for qemu-devel@nongnu.org; Fri, 10 Apr 2015 04:14:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgU52-0006bM-NE for qemu-devel@nongnu.org; Fri, 10 Apr 2015 04:14:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33950) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgU52-0006ao-Gn for qemu-devel@nongnu.org; Fri, 10 Apr 2015 04:14:24 -0400 Message-ID: <55278657.8080306@redhat.com> Date: Fri, 10 Apr 2015 10:14:15 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] How address_space_rw works? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kaiyuan Cc: Peter Maydell , qemu-devel On 10/04/2015 09:47, Kaiyuan wrote: >>> Where is the code location that I can set breakpoint to observe >>> the fast path for R/W requests to RAM? >> >> Nowhere really, because the fast path is done directly in assembly >> code that TCG generates at run-time. >> >>> Whether dose Qemu provide method to disable fast path so that I >>> can set one breakpoint to catch all requests both MMIO and RAM? >> >> You can modify the backends (e.g. tcg/i386/tcg-target.c) to do >> this, but chances are that there is a better way to do it. > > The request address I get from backends is host virtual address. But, > only guest physical address is useful to me. The backends are passed guest virtual addresses for the qemu_ld and qemu_st TCG opcodes. >> What are you trying to do? > > Thanks for your answer. I need to implement a checker that locates > logically between bus and memory. This checker will catch all access > requests, check if the address of requests are in a table I maintain. > If address is in table, checker will forwards request to memory. If > address is not in table, request will be discarded. You can think it > as a firewall for addresses of R/W access requests. If that's the case, you could also add your check to memory_region_section_get_iotlb. Search for PHYS_SECTION_WATCH, watch_mem_ops and io_mem_watch, and do the same for your new special case. This is where QEMU decides between using the slow path or the fast path. However this will not catch instruction fetches. How to do that depends on the details of what you are doing. In particular, if you need to trap on _all_ instruction fetches and not just the first, it's likely that QEMU is not the best project to base your changes on. A simulator would be more appropriate. Paolo