From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kai Huang Subject: Re: [PATCH 5/6] KVM: x86: Add new dirty logging kvm_x86_ops for PML Date: Thu, 05 Feb 2015 14:29:17 +0800 Message-ID: <54D30DBD.2020300@linux.intel.com> References: <1422413668-3509-1-git-send-email-kai.huang@linux.intel.com> <1422413668-3509-6-git-send-email-kai.huang@linux.intel.com> <20150203155302.GE19731@potion.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: pbonzini@redhat.com, gleb@kernel.org, linux@arm.linux.org.uk, kvm@vger.kernel.org To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: Received: from mga09.intel.com ([134.134.136.24]:55321 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756601AbbBEGhf (ORCPT ); Thu, 5 Feb 2015 01:37:35 -0500 In-Reply-To: <20150203155302.GE19731@potion.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/03/2015 11:53 PM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > 2015-01-28 10:54+0800, Kai Huang: >> This patch adds new kvm_x86_ops dirty logging hooks to enable/disabl= e dirty >> logging for particular memory slot, and to flush potentially logged = dirty GPAs >> before reporting slot->dirty_bitmap to userspace. >> >> kvm x86 common code calls these hooks when they are available so PML= logic can >> be hidden to VMX specific. Other ARCHs won't be impacted as these ho= oks are NULL >> for them. >> >> Signed-off-by: Kai Huang >> --- >> --- a/arch/x86/include/asm/kvm_host.h >> +++ b/arch/x86/include/asm/kvm_host.h >> @@ -802,6 +802,31 @@ struct kvm_x86_ops { >> + >> + /* >> + * Arch-specific dirty logging hooks. These hooks are only suppose= d to >> + * be valid if the specific arch has hardware-accelerated dirty lo= gging >> + * mechanism. Currently only for PML on VMX. >> + * >> + * - slot_enable_log_dirty: >> + * called when enabling log dirty mode for the slot. > (I guess that "log dirty mode" isn't the meaning that people will thi= nk > after seeing 'log_dirty' ... > I'd at least change 'log_dirty' to 'dirty_log' in these names.) > >> + * - slot_disable_log_dirty: >> + * called when disabling log dirty mode for the slot. >> + * also called when slot is created with log dirty disabled. >> + * - flush_log_dirty: >> + * called before reporting dirty_bitmap to userspace. >> + * - enable_log_dirty_pt_masked: >> + * called when reenabling log dirty for the GFNs in the mask after >> + * corresponding bits are cleared in slot->dirty_bitmap. > This name is very confusing ... I think we should hint that this is > called after we learn that the page has been written to and would lik= e > to monitor it again. > > Using something like collected/refresh? (I'd have to do horrible thi= ngs > to come up with a good name, sorry.) > >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -3780,6 +3780,12 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kv= m, struct kvm_dirty_log *log) >> =20 >> mutex_lock(&kvm->slots_lock); >> =20 >> + /* >> + * Flush potentially hardware-cached dirty pages to dirty_bitmap. >> + */ >> + if (kvm_x86_ops->flush_log_dirty) >> + kvm_x86_ops->flush_log_dirty(kvm); > (Flushing would make more sense in kvm_get_dirty_log_protect().) > >> + >> r =3D kvm_get_dirty_log_protect(kvm, log, &is_dirty); >> =20 >> /* >> @@ -7533,6 +7539,56 @@ int kvm_arch_prepare_memory_region(struct kvm= *kvm, >> return 0; >> } >> =20 >> +static void kvm_mmu_slot_apply_flags(struct kvm *kvm, >> + struct kvm_memory_slot *new) >> +{ >> + /* Still write protect RO slot */ >> + if (new->flags & KVM_MEM_READONLY) { >> + kvm_mmu_slot_remove_write_access(kvm, new); > We didn't write protect RO slots before, does this patch depend on it= ? No PML doesn't depend on it to work. It's suggested by Paolo. Thanks, -Kai > >> @@ -7562,16 +7618,15 @@ void kvm_arch_commit_memory_region(struct kv= m *kvm, >> - if ((change !=3D KVM_MR_DELETE) && (new->flags & KVM_MEM_LOG_DIRTY= _PAGES)) >> - kvm_mmu_slot_remove_write_access(kvm, new); >> + if (change !=3D KVM_MR_DELETE) >> + kvm_mmu_slot_apply_flags(kvm, new);