From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: [PATCH 2/6] qemu-kvm: Modify and introduce wrapper functions to access phys_ram_dirty. Date: Wed, 17 Mar 2010 06:07:39 +0200 Message-ID: <4BA0558B.2000400@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , ohmura.kei@lab.ntt.co.jp, Yoshiaki Tamura , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Blue Swirl Return-path: Received: from mx1.redhat.com ([209.132.183.28]:6788 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751413Ab0CQEHu (ORCPT ); Wed, 17 Mar 2010 00:07:50 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 03/16/2010 10:10 PM, Blue Swirl wrote: > >> Yes, and is what tlb_protect_code() does and it's called from >> tb_alloc_page() which is what's code when a TB is created. >> > 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 > On x86 you're supposed to execute a serializing instruction (one of INVD, INVEPT, INVLPG, INVVPID, LGDT, LIDT, LLDT, LTR, MOV (to control register, with the exception of MOV CR8), MOV (to debug register), WBINVD, WRMSR, CPUID, IRET, and RSM) before running modified code. > but I suppose SMC is pretty rare. > Every time you demand load a code page from disk, you're running self modifying code (though it usually doesn't exist in the tlb, so there's no previous version that can cause trouble). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.