From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJP4C-0006mN-5K for qemu-devel@nongnu.org; Wed, 13 Jan 2016 12:18:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJP4B-00059t-8y for qemu-devel@nongnu.org; Wed, 13 Jan 2016 12:18:40 -0500 Received: from mail-vk0-x232.google.com ([2607:f8b0:400c:c05::232]:35910) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJP4B-00059j-4N for qemu-devel@nongnu.org; Wed, 13 Jan 2016 12:18:39 -0500 Received: by mail-vk0-x232.google.com with SMTP id n1so110804123vkb.3 for ; Wed, 13 Jan 2016 09:18:38 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: From: Peter Maydell Date: Wed, 13 Jan 2016 17:18:19 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] Question regarding self-modifying code. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: farmdve Cc: QEMU Developers On 13 January 2016 at 16:45, farmdve wrote: > On Windows, in software MMU mode, how does QEMU handle > self-modifying code? When we translate the guest code in a page of guest memory, we mark that page as "not dirty for code" by calling tlb_protect_code(), which clears a DIRTY_MEMORY_CODE bit and also ensures that subsequent guest writes to this page will take a slow code path. On that slow code path (in notdirty_mem_write()) we check to see if the DIRTY_MEMORY_CODE flag is clear for this page, and if it is then we throw away the translated code by calling tb_invalidate_phys_page_fast(). If the guest later tries to execute from the page again, we will translate the guest code again (and so will use the freshly modified code). There is some slight extra complication for CPUs which can validly modify the code they're executing (ie which don't need any kind of "flush cache/pipeline" or a branch between the store which modifies the code and the execution of the modified code). You can find those by looking at the changes controlled by the TARGET_HAS_PRECISE_SMC #define, which we only need for x86 guests at the moment. (For CPUs which don't set that, attempting to self-modify code in the same TB won't work, which is OK because architecturally that doesn't work on hardware either.) thanks -- PMM