From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: Calling to kvm_mmu_load Date: Tue, 29 Oct 2013 13:55:58 +0100 Message-ID: <526FB05E.1070204@redhat.com> References: <52676AF4.4080906@redhat.com> <5269BEAC.90809@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kvm , Jan Kiszka To: Arthur Chunqi Li Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52207 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751237Ab3J2M4E (ORCPT ); Tue, 29 Oct 2013 08:56:04 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Il 29/10/2013 06:39, Arthur Chunqi Li ha scritto: > What is the dirty page tracking code path? I find a obsoleted flag > "dirty_page_log_all" in the very previous codes, but I cannot get the > most recent version of tracking dirty pages. Basically everything that accesses the dirty_bitmap field of struct kvm_memory_slot is involved. It all starts when the KVM_SET_USER_MEMORY_REGION ioctl is called with the KVM_MEM_LOG_DIRTY_PAGES flag set. > Besides, I noticed that memory management in KVM uses the mechanism > with "struct kvm_memory_slot". How is kvm_memory_slot used with the > cooperation of Linux memory management? kvm_memory_slot just maps a host userspace address range to a guest physical address range. Cooperation with Linux memory management is done with the Linux MMU notifiers. MMU notifiers let KVM know that a page has been swapped out, and KVM reacts by invalidating the shadow page tables for the corresponding guest physical address. Paolo