From mboxrd@z Thu Jan 1 00:00:00 1970 From: Min-gyu Kim Subject: RE: [kvmarm] [PATCH v2 06/14] KVM: ARM: Memory virtualization setup Date: Wed, 10 Oct 2012 10:02:11 +0900 Message-ID: <001501cda682$e220eba0$a662c2e0$@samsung.com> References: <20121001090945.49198.68950.stgit@ubuntu> <20121001091042.49198.93241.stgit@ubuntu> <000401cda2a0$69670a40$3c351ec0$@samsung.com> <6994599196536c9557528c465f8f93b0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?utf-8?B?J+q5gOywve2ZmCc=?= , linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu To: 'Marc Zyngier' , 'Christoffer Dall' Return-path: Received: from mailout3.samsung.com ([203.254.224.33]:32339 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755184Ab2JJBC1 convert rfc822-to-8bit (ORCPT ); Tue, 9 Oct 2012 21:02:27 -0400 Received: from epcpsbgm2.samsung.com (epcpsbgm2 [203.254.230.27]) by mailout3.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MBN00EG2K66URE0@mailout3.samsung.com> for kvm@vger.kernel.org; Wed, 10 Oct 2012 10:02:17 +0900 (KST) Received: from MingyuPC ([182.198.1.3]) by mmp2.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0MBN006NEK7RAX50@mmp2.samsung.com> for kvm@vger.kernel.org; Wed, 10 Oct 2012 10:02:17 +0900 (KST) In-reply-to: <6994599196536c9557528c465f8f93b0@localhost> Content-language: ko Sender: kvm-owner@vger.kernel.org List-ID: > -----Original Message----- > From: Marc Zyngier [mailto:marc.zyngier@arm.com] > Sent: Tuesday, October 09, 2012 9:56 PM > To: Christoffer Dall > Cc: Min-gyu Kim; =EA=B9=80=EC=B0=BD=ED=99=98; linux-arm-kernel@lists.= infradead.org; > kvm@vger.kernel.org; kvmarm@lists.cs.columbia.edu > Subject: Re: [kvmarm] [PATCH v2 06/14] KVM: ARM: Memory virtualizatio= n > setup >=20 > On Sat, 6 Oct 2012 17:33:43 -0400, Christoffer Dall > wrote: > > On Thu, Oct 4, 2012 at 10:23 PM, Min-gyu Kim > > > > wrote: > >> > >> > >>> -----Original Message----- > >>> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org= ] > >>> On Behalf Of Christoffer Dall > >>> Sent: Monday, October 01, 2012 6:11 PM > >>> To: kvm@vger.kernel.org; linux-arm-kernel@lists.infradead.org; > >>> kvmarm@lists.cs.columbia.edu > >>> Cc: Marc Zyngier > >>> Subject: [PATCH v2 06/14] KVM: ARM: Memory virtualization setup > >>> > >>> +static void stage2_set_pte(struct kvm *kvm, struct > kvm_mmu_memory_cache > >>> *cache, > >>> + phys_addr_t addr, const pte_t *new_pte) = { > >>> + pgd_t *pgd; > >>> + pud_t *pud; > >>> + pmd_t *pmd; > >>> + pte_t *pte, old_pte; > >>> + > >>> + /* Create 2nd stage page table mapping - Level 1 */ > >>> + pgd =3D kvm->arch.pgd + pgd_index(addr); > >>> + pud =3D pud_offset(pgd, addr); > >>> + if (pud_none(*pud)) { > >>> + if (!cache) > >>> + return; /* ignore calls from kvm_set_spte_h= va */ > >>> + pmd =3D mmu_memory_cache_alloc(cache); > >>> + pud_populate(NULL, pud, pmd); > >>> + pmd +=3D pmd_index(addr); > >>> + get_page(virt_to_page(pud)); > >>> + } else > >>> + pmd =3D pmd_offset(pud, addr); > >>> + > >>> + /* Create 2nd stage page table mapping - Level 2 */ > >>> + if (pmd_none(*pmd)) { > >>> + if (!cache) > >>> + return; /* ignore calls from kvm_set_spte_h= va */ > >>> + pte =3D mmu_memory_cache_alloc(cache); > >>> + clean_pte_table(pte); > >>> + pmd_populate_kernel(NULL, pmd, pte); > >>> + pte +=3D pte_index(addr); > >>> + get_page(virt_to_page(pmd)); > >>> + } else > >>> + pte =3D pte_offset_kernel(pmd, addr); > >>> + > >>> + /* Create 2nd stage page table mapping - Level 3 */ > >>> + old_pte =3D *pte; > >>> + set_pte_ext(pte, *new_pte, 0); > >>> + if (pte_present(old_pte)) > >>> + __kvm_tlb_flush_vmid(kvm); > >>> + else > >>> + get_page(virt_to_page(pte)); } > >> > >> > >> I'm not sure about the 3-level page table, but isn't it necessary = to > >> clean the page table for 2nd level? > >> There are two mmu_memory_cache_alloc calls. One has following > >> clean_pte_table and the other doesn't have. > > > > hmm, it probably is - I couldn't really find the common case where > > this is done in the kernel normally (except for some custom loop in > > ioremap and idmap), but I added this fix: > > > > diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index > > 5394a52..f11ba27f 100644 > > --- a/arch/arm/kvm/mmu.c > > +++ b/arch/arm/kvm/mmu.c > > @@ -430,6 +430,7 @@ static void stage2_set_pte(struct kvm *kvm, str= uct > > kvm_mmu_memory_cache *cache, > > if (!cache) > > return; /* ignore calls from kvm_set_spte_hva */ > > pmd =3D mmu_memory_cache_alloc(cache); > > + clean_dcache_area(pmd, PTRS_PER_PMD * sizeof(pmd_t)); > > pud_populate(NULL, pud, pmd); > > pmd +=3D pmd_index(addr); > > get_page(virt_to_page(pud)); >=20 > There ought to be a test of ID_MMFR3[23:20] to find out whether or no= t it > is useful to clean the dcache. Not sure if that's a massive gain, but= it > is certainly an optimisation to consider for the kernel as a whole. That's part of what I was wondering. clean_dcache_area is substituted b= y nop if TLB_CAN_READ_FROM_L1_CACHE is defined(mm/proc-v7.S).=20 But I couldn't find any place where it is defined. If it is part of bsp to enable TLB_CAN_RAD_FROM_L1_CACHE according to I= D_MMFR3[23:20], it would not be necessary to concerned about cleaning or not cleaning. However, am I right? >=20 > M. > -- > Fast, cheap, reliable. Pick two.