Received: by 2002:ac0:950e:0:0:0:0:0 with SMTP id f14csp1149222imc; Sun, 17 Mar 2019 05:35:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqz56mawgYhRCUhNL/tJFeLr3mono1hv08ExqH4KV1ahBrfCa+iGhJj+aKBNI6TpF6D3BKd+ X-Received: by 2002:a17:902:b698:: with SMTP id c24mr6239056pls.221.1552826145452; Sun, 17 Mar 2019 05:35:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552826145; cv=none; d=google.com; s=arc-20160816; b=0zC8fhrJjIBozEpp8ASA2hT32tw6kxf/6SHTEdEjbjhPPyaEpTA7WPMHy4786TM5Np gxaJbu/0NQZQLl7ip/xoN+OP4a6oFRnoLUCUtqctY2SRRKj0z6jyT0tNgAFloiN9lJw4 7O9ks7//pCQ7F+c7go2OIKY1BzCWze7xG0sX/bC2CClJJs+tWw7Zmn6+wO35pbs1PPg0 k7J/ZW54SeYGaRplTtoTSpo4WddgOiemfBao5z+xOGypeJ2PPZCSmGyArIUxLU1is4C+ dReudWavJU6YqLrhJMe3JzBZa1uZ2/2f33q+6bi+/PFouYG59syYK3+x51qhvPy4jpG9 rnow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=7dtdbKypDOPGKvWfLqzIPx56Hpkl9hyk4FrgbQITNeQ=; b=f5YNcVNS7/bXRJ/11nE/CW+Iext7sOcBwvVkl+VhBpqbNAmLyEpuARp+XP6YpnwPDx Nf/9UTbUxGAq1tjfWO2YuygJcixRsGyiSSUT5yKmIFQSMSSqExn8m3oY6igcyuq/+Ocn 5CENe3X3uChfEGLbWZJkIerwwh4txWyGhR4jp+6rEVIGw6Ks5GBop3I12NsbARUDyVL5 TSAuZn4XwIhoDkS0nI3EIFRmA7QsnreCtLvGi2mVlKcYTEgUxBFgeAuBSntFCKZUDIe/ utmsn0i7CRSeMZDfJLQKzQAF/WoB5eTLZkBn4InReNubksYt+7AlMlCsypZDpiAzfnnT 2ALQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 189si6496919pgb.412.2019.03.17.05.35.30; Sun, 17 Mar 2019 05:35:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727165AbfCQMey (ORCPT + 99 others); Sun, 17 Mar 2019 08:34:54 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:4695 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726204AbfCQMey (ORCPT ); Sun, 17 Mar 2019 08:34:54 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 38F05DCEC73DB19DA2F0; Sun, 17 Mar 2019 20:34:50 +0800 (CST) Received: from [127.0.0.1] (10.184.12.158) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.408.0; Sun, 17 Mar 2019 20:34:43 +0800 Subject: Re: [PATCH] kvm: arm: Enforce PTE mappings at stage2 when needed To: Suzuki K Poulose , CC: , , , , , Christoffer Dall , "Marc Zyngier" References: <1552384371-10772-1-git-send-email-suzuki.poulose@arm.com> From: Zenghui Yu Message-ID: <902e339c-fcbd-b44d-6549-9770b15e050a@huawei.com> Date: Sun, 17 Mar 2019 20:33:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:64.0) Gecko/20100101 Thunderbird/64.0 MIME-Version: 1.0 In-Reply-To: <1552384371-10772-1-git-send-email-suzuki.poulose@arm.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.184.12.158] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Suzuki, On 2019/3/12 17:52, Suzuki K Poulose wrote: > commit 6794ad5443a2118 ("KVM: arm/arm64: Fix unintended stage 2 PMD mappings") > made the checks to skip huge mappings, stricter. However it introduced > a bug where we still use huge mappings, ignoring the flag to > use PTE mappings, by not reseting the vma_pagesize to PAGE_SIZE. > > Also, the checks do not cover the PUD huge pages, that was > under review during the same period. This patch fixes both > the issues. > > Fixes : 6794ad5443a2118 ("KVM: arm/arm64: Fix unintended stage 2 PMD mappings") > Reported-by: Zenghui Yu > Cc: Zenghui Yu > Cc: Christoffer Dall > Cc: Marc Zyngier > Signed-off-by: Suzuki K Poulose > --- Thanks for Cc-ing me. It works fine now! zenghui > virt/kvm/arm/mmu.c | 43 +++++++++++++++++++++---------------------- > 1 file changed, 21 insertions(+), 22 deletions(-) > > diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c > index 30251e2..66e0fbb5 100644 > --- a/virt/kvm/arm/mmu.c > +++ b/virt/kvm/arm/mmu.c > @@ -1595,8 +1595,9 @@ static void kvm_send_hwpoison_signal(unsigned long address, > send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current); > } > > -static bool fault_supports_stage2_pmd_mappings(struct kvm_memory_slot *memslot, > - unsigned long hva) > +static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot, > + unsigned long hva, > + unsigned long map_size) > { > gpa_t gpa_start, gpa_end; > hva_t uaddr_start, uaddr_end; > @@ -1612,34 +1613,34 @@ static bool fault_supports_stage2_pmd_mappings(struct kvm_memory_slot *memslot, > > /* > * Pages belonging to memslots that don't have the same alignment > - * within a PMD for userspace and IPA cannot be mapped with stage-2 > - * PMD entries, because we'll end up mapping the wrong pages. > + * within a PMD/PUD for userspace and IPA cannot be mapped with stage-2 > + * PMD/PUD entries, because we'll end up mapping the wrong pages. > * > * Consider a layout like the following: > * > * memslot->userspace_addr: > * +-----+--------------------+--------------------+---+ > - * |abcde|fgh Stage-1 PMD | Stage-1 PMD tv|xyz| > + * |abcde|fgh Stage-1 block | Stage-1 block tv|xyz| > * +-----+--------------------+--------------------+---+ > * > * memslot->base_gfn << PAGE_SIZE: > * +---+--------------------+--------------------+-----+ > - * |abc|def Stage-2 PMD | Stage-2 PMD |tvxyz| > + * |abc|def Stage-2 block | Stage-2 block |tvxyz| > * +---+--------------------+--------------------+-----+ > * > - * If we create those stage-2 PMDs, we'll end up with this incorrect > + * If we create those stage-2 blocks, we'll end up with this incorrect > * mapping: > * d -> f > * e -> g > * f -> h > */ > - if ((gpa_start & ~S2_PMD_MASK) != (uaddr_start & ~S2_PMD_MASK)) > + if ((gpa_start & (map_size - 1)) != (uaddr_start & (map_size - 1))) > return false; > > /* > * Next, let's make sure we're not trying to map anything not covered > - * by the memslot. This means we have to prohibit PMD size mappings > - * for the beginning and end of a non-PMD aligned and non-PMD sized > + * by the memslot. This means we have to prohibit block size mappings > + * for the beginning and end of a non-block aligned and non-block sized > * memory slot (illustrated by the head and tail parts of the > * userspace view above containing pages 'abcde' and 'xyz', > * respectively). > @@ -1648,8 +1649,8 @@ static bool fault_supports_stage2_pmd_mappings(struct kvm_memory_slot *memslot, > * userspace_addr or the base_gfn, as both are equally aligned (per > * the check above) and equally sized. > */ > - return (hva & S2_PMD_MASK) >= uaddr_start && > - (hva & S2_PMD_MASK) + S2_PMD_SIZE <= uaddr_end; > + return (hva & ~(map_size - 1)) >= uaddr_start && > + (hva & ~(map_size - 1)) + map_size <= uaddr_end; > } > > static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > @@ -1678,12 +1679,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > return -EFAULT; > } > > - if (!fault_supports_stage2_pmd_mappings(memslot, hva)) > - force_pte = true; > - > - if (logging_active) > - force_pte = true; > - > /* Let's check if we will get back a huge page backed by hugetlbfs */ > down_read(¤t->mm->mmap_sem); > vma = find_vma_intersection(current->mm, hva, hva + 1); > @@ -1694,6 +1689,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > } > > vma_pagesize = vma_kernel_pagesize(vma); > + if (logging_active || > + !fault_supports_stage2_huge_mapping(memslot, hva, vma_pagesize)) { > + force_pte = true; > + vma_pagesize = PAGE_SIZE; > + } > + > /* > * The stage2 has a minimum of 2 level table (For arm64 see > * kvm_arm_setup_stage2()). Hence, we are guaranteed that we can > @@ -1701,11 +1702,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > * As for PUD huge maps, we must make sure that we have at least > * 3 levels, i.e, PMD is not folded. > */ > - if ((vma_pagesize == PMD_SIZE || > - (vma_pagesize == PUD_SIZE && kvm_stage2_has_pmd(kvm))) && > - !force_pte) { > + if (vma_pagesize == PMD_SIZE || > + (vma_pagesize == PUD_SIZE && kvm_stage2_has_pmd(kvm))) > gfn = (fault_ipa & huge_page_mask(hstate_vma(vma))) >> PAGE_SHIFT; > - } > up_read(¤t->mm->mmap_sem); > > /* We need minimum second+third level pages */ >