From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37161) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgSWv-0007sw-F6 for qemu-devel@nongnu.org; Fri, 10 Apr 2015 02:35:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgSWs-0005vL-8X for qemu-devel@nongnu.org; Fri, 10 Apr 2015 02:35:05 -0400 Received: from mail-wg0-x236.google.com ([2a00:1450:400c:c00::236]:33166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgSWs-0005uZ-0z for qemu-devel@nongnu.org; Fri, 10 Apr 2015 02:35:02 -0400 Received: by wgin8 with SMTP id n8so7980321wgi.0 for ; Thu, 09 Apr 2015 23:35:01 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <55276F10.8010802@redhat.com> Date: Fri, 10 Apr 2015 08:34:56 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] How address_space_rw works? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kaiyuan , Peter Maydell Cc: qemu-devel On 10/04/2015 06:47, Kaiyuan wrote: >> That's because we have a fast-path for RAM accesses that directs >> them to the bit of host memory we're using as guest RAM: >> * for KVM, the guest gets the host memory directly mapped and >> accesses it without trapping out to userspace >> * for TCG, our TLB data structure caches the guest-virtual-address >> to host-virtual-address mapping, and the generated TCG code >> does a fast inline lookup in this cache; if it hits then it >> can load or store to the host memory without ever having to >> come out to a C helper function > > Thanks for your explanation about fast path. I am reviewing and debugging code related to TCG. > > 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. What are you trying to do? Paolo