From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B3A1C4360F for ; Mon, 1 Apr 2019 17:10:53 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 29DF021A4A for ; Mon, 1 Apr 2019 17:10:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UayNXv9a" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29DF021A4A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=v6iecv4WuefsM1G9KIE9RQOMPTM0YlLNXqaWF0PqwUI=; b=UayNXv9aYzepO2 L9aIV9NmwNvuEQ/n7r6MBQ0H8URurb7uBk+60WCYzqAA0fywDkThLo2T9EByRVaeBS+X+5gZByKIT zJPGmmjdnTJOx0k7I2lj+qymZb4hiWts8NqgPmuCsMN2qZsz1yPZQ/oSZgg2lg1WypckXb4oWa0Oi LUTza00p5q9DoSFKQcESn6FVI6lKDyd30cnv2ZbUBhUbRf0aNduuvNzG05EA330BJ0hyPOqoySFEs LJwBM9tkINuHtkMz/seqO5Sl17Y/GEVQfnRlFTZoq7fcjaCGFmbtLeeBXYxMPo9lgGYXDNtgAA/hq 7eXiFVUfheAyBBtHok4w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hB0SN-00019e-Nc; Mon, 01 Apr 2019 17:10:47 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hB0SK-00019D-MJ for linux-arm-kernel@lists.infradead.org; Mon, 01 Apr 2019 17:10:46 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 909DCF74B5; Mon, 1 Apr 2019 17:10:43 +0000 (UTC) Received: from [10.36.117.163] (ovpn-117-163.ams2.redhat.com [10.36.117.163]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 92D171001DD8; Mon, 1 Apr 2019 17:10:39 +0000 (UTC) Subject: Re: [PATCH 5/8] KVM: arm/arm64: Enforce PTE mappings at stage2 when needed To: Marc Zyngier , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= References: <20190328133608.110805-1-marc.zyngier@arm.com> <20190328133608.110805-6-marc.zyngier@arm.com> From: Auger Eric Message-ID: <496ad70d-eaa5-c46e-ddf0-d07607522eeb@redhat.com> Date: Mon, 1 Apr 2019 19:10:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190328133608.110805-6-marc.zyngier@arm.com> Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 01 Apr 2019 17:10:43 +0000 (UTC) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190401_101044_772274_57337254 X-CRM114-Status: GOOD ( 28.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, Suzuki K Poulose , Julien Thierry , YueHaibing , Zheng Xiang , Shameerali Kolothum Thodi , Christoffer Dall , Julien Grall , James Morse , Nianyao Tang , Zenghui Yu , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Suzuki, On 3/28/19 2:36 PM, Marc Zyngier wrote: > From: Suzuki K Poulose > > 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. I face a regression with this patch. My guest gets stuck. I am running on AMD Seattle. Reverting the patch makes things work again for me. I run with qemu. In this scenario I don't use hugepages. I use 64kB page size for both the host and guest. Thanks Eric > > Fixes : 6794ad5443a2118 ("KVM: arm/arm64: Fix unintended stage 2 PMD mappings") > Reported-by: Zenghui Yu > Cc: Zenghui Yu > Cc: Christoffer Dall > Signed-off-by: Suzuki K Poulose > Signed-off-by: Marc Zyngier > --- > 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 ffd7acdceac7..bcdf978c0d1d 100644 > --- a/virt/kvm/arm/mmu.c > +++ b/virt/kvm/arm/mmu.c > @@ -1594,8 +1594,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; > hva_t uaddr_start, uaddr_end; > @@ -1610,34 +1611,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). > @@ -1646,8 +1647,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, > @@ -1676,12 +1677,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); > @@ -1692,6 +1687,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 > @@ -1699,11 +1700,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 */ > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel