From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NrfIv-0002Dp-9j for qemu-devel@nongnu.org; Tue, 16 Mar 2010 18:32:01 -0400 Received: from [199.232.76.173] (port=55195 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NrfIu-0002D8-P9 for qemu-devel@nongnu.org; Tue, 16 Mar 2010 18:32:00 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NrfIs-0003pf-Aw for qemu-devel@nongnu.org; Tue, 16 Mar 2010 18:32:00 -0400 Received: from are.twiddle.net ([75.149.56.221]:39133) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NrfIs-0003pV-0Z for qemu-devel@nongnu.org; Tue, 16 Mar 2010 18:31:58 -0400 Message-ID: <4BA006DB.3070205@twiddle.net> Date: Tue, 16 Mar 2010 15:31:55 -0700 From: Richard Henderson MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2/6] qemu-kvm: Modify and introduce wrapper functions to access phys_ram_dirty. References: <1268736839-27371-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <1268736839-27371-3-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <4B9F7D78.5090201@redhat.com> <4B9F8502.3070108@lab.ntt.co.jp> <4B9F87A9.3070509@redhat.com> <4B9F8CE2.7010104@codemonkey.ws> <4B9F8E4C.5070307@redhat.com> <4B9F9A9D.6000302@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: ohmura.kei@lab.ntt.co.jp, kvm@vger.kernel.org, Yoshiaki Tamura , qemu-devel@nongnu.org, Avi Kivity On 03/16/2010 01:10 PM, Blue Swirl wrote: > Just a tangential note: a long time ago, I tried to disable self > modifying code detection for Sparc. On most RISC architectures, SMC > needs explicit flushing so in theory we need not track code memory > writes. However, during exceptions the translator needs to access the > original unmodified code that was used to generate the TB. But maybe > there are other ways to avoid SMC tracking, on x86 it's still needed > but I suppose SMC is pretty rare. True SMC is fairly rare, but the SMC checker triggers fairly often on the PLT update during dynamic linking. Nearly all cpus (x86 being the only exception I recall) needed to re-design their PLT format to avoid this code update in order to support SELinux. Where does the translator need access to this original code? I was just thinking about this problem today, wondering how much overhead there is with this SMC page protection thing. r~