From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mario Smarduch Subject: Re: [PATCH v12 2/6] KVM: Add generic support for dirty page logging Date: Mon, 03 Nov 2014 11:34:03 -0800 Message-ID: <5457D8AB.2080507@samsung.com> References: <1414017251-5772-1-git-send-email-m.smarduch@samsung.com> <1414017251-5772-3-git-send-email-m.smarduch@samsung.com> <20141030131430.5b50a7c0.cornelia.huck@de.ibm.com> <54528F24.6060602@samsung.com> <20141103120149.01a61560dabe267b89a2478a@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Cornelia Huck , kvmarm@lists.cs.columbia.edu, christoffer.dall@linaro.org, pbonzini@redhat.com, agraf@suse.de, catalin.marinas@arm.com, borntraeger@de.ibm.com, james.hogan@imgtec.com, marc.zyngier@arm.com, xiaoguangrong@linux.vnet.ibm.com, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, kvm-ia64@vger.kernel.org, linux-arm-kernel@lists.infradead.org, steve.capper@arm.com, peter.maydell@linaro.org To: Takuya Yoshikawa Return-path: In-reply-to: <20141103120149.01a61560dabe267b89a2478a@gmail.com> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 11/02/2014 07:01 PM, Takuya Yoshikawa wrote: > On Thu, 30 Oct 2014 12:19:00 -0700 > Mario Smarduch wrote: > >> On 10/30/2014 05:14 AM, Cornelia Huck wrote: >>> On Wed, 22 Oct 2014 15:34:07 -0700 >>> Mario Smarduch wrote: >>> >>>> This patch defines KVM_GENERIC_DIRTYLOG, and moves dirty log read function >>>> to it's own file virt/kvm/dirtylog.c. x86 is updated to use the generic >>>> dirty log interface, selecting KVM_GENERIC_DIRTYLOG in its Kconfig and >>>> makefile. No other architectures are affected, each uses it's own version. >>>> This changed from previous patch revision where non-generic architectures >>>> were modified. >>>> >>>> In subsequent patch armv7 does samething. All other architectures continue >>>> use architecture defined version. >>>> >>> >>> Hm. >>> >>> "The x86 specific version of dirty page logging is generic enough to be >>> used by other architectures, noteably ARMv7. So let's move the x86 code >>> under virt/kvm/ and make it depend on KVM_GENERIC_DIRTYLOG. Other >>> architectures continue to use their own implementations." >>> >>> ? >> >> I'll update descriptions for both patches, with the more concise >> descriptions. > > I don't think it's so generic. > > Especially, the relationship between mmu_lock and TLB flushing has > been changed a few times for optimizing x86 mmu code, and it may change > in the future again. > > Since how mmu_lock is used is depends on each arch, it's not so > simple to make the function generic IMO. > > Thanks, > Takuya Hi Takuya, If the bitmap can be processed locklessly then it's not reusable for sure. The interface is not "to generic", but "generic enough" for arm/armv8 to reuse. For TLB flushing I would think optimizations would wind up in arch subtree. I'm not convinced that location of couple lines doesn't make the interface re-usable, going back to 3.10 it hardly changed. - Mario > >> >> Thanks. >> >>> >>>> >>>> Signed-off-by: Mario Smarduch >>>> --- >>>> arch/x86/include/asm/kvm_host.h | 3 -- >>>> arch/x86/kvm/Kconfig | 1 + >>>> arch/x86/kvm/Makefile | 1 + >>>> arch/x86/kvm/x86.c | 86 ------------------------------ >>>> include/linux/kvm_host.h | 4 ++ >>>> virt/kvm/Kconfig | 3 ++ >>>> virt/kvm/dirtylog.c | 112 +++++++++++++++++++++++++++++++++++++++ >>>> 7 files changed, 121 insertions(+), 89 deletions(-) >>>> create mode 100644 virt/kvm/dirtylog.c >>>> >>> >>>> diff --git a/virt/kvm/dirtylog.c b/virt/kvm/dirtylog.c >>>> new file mode 100644 >>>> index 0000000..67ffffa >>>> --- /dev/null >>>> +++ b/virt/kvm/dirtylog.c >>>> @@ -0,0 +1,112 @@ >>>> +/* >>>> + * kvm generic dirty logging support, used by architectures that share >>>> + * comman dirty page logging implementation. >>> >>> s/comman/common/ >>> >>> The approach looks sane to me, especially as it does not change other >>> architectures needlessly. >>> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe kvm" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >