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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 76DFEC3DA4A for ; Thu, 22 Aug 2024 06:33:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=v9L+ux6eqpfs8HzsN5Mc/twSCks2uxys4IF0TgSNQbs=; b=zRQ+vtWlmg795VpEZP0mNdM7IE 9wgmFWgUliNht0K3VDWzVzvxhVCNJlDWgEhilKv/USUWwnHkZ4Ib9hsXoiCkX/dUOK285I3Ixv9OK rlhR5QhOWmmU2X207wh28QG7NgUheIGIj0EZj3drCiFn5fdVKDLdBwiP2aOLUgpE3BBkL2HoCf9GN KZjQh+iWPONW6YZ9LmWulLdI8HKufgBcAPpjTuyGOFr/VgK7ca4Xh2L6SYOY1t2qq6+UYJYrShWnC RAFAtXpdbepm3ux3AibH8ytMRFSOoMnBh4syAPIKGqhySYbUy/7O/RuJogH6uNtbHCun38BKBu+7w qPjq04eg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sh1NR-0000000BcSC-1jXN; Thu, 22 Aug 2024 06:32:57 +0000 Received: from out-183.mta0.migadu.com ([91.218.175.183]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sh1M4-0000000Bc4t-2DQm for linux-arm-kernel@lists.infradead.org; Thu, 22 Aug 2024 06:31:34 +0000 Date: Thu, 22 Aug 2024 06:31:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724308285; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=v9L+ux6eqpfs8HzsN5Mc/twSCks2uxys4IF0TgSNQbs=; b=RvmEtmEWo3qrdEPjK0SFllLxQkoGLfOYCr3K1MEV0ZjxRzgIURV9s1vbQoXCQJzDJ1duMt sSnffekuUeXRsaafxh/3HzZC0+r2s17FUjz0UodRzfKAXUVtENu164VbYiWAHZC+1BK+aB gY/zvvLXMOInTeVNdfCWhKgDTpTgrOY= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Zenghui Yu Cc: Marc Zyngier , kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, James Morse , Suzuki K Poulose , Joey Gouly , Alexandru Elisei , Christoffer Dall , Ganapatrao Kulkarni Subject: Re: [PATCH v3 03/16] KVM: arm64: nv: Handle shadow stage 2 page faults Message-ID: References: <20240614144552.2773592-1-maz@kernel.org> <20240614144552.2773592-4-maz@kernel.org> <9ba30187-6630-02e6-d755-7d1b39118a32@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ba30187-6630-02e6-d755-7d1b39118a32@huawei.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240821_233133_025126_59C74230 X-CRM114-Status: GOOD ( 23.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Aug 22, 2024 at 03:11:16AM +0800, Zenghui Yu wrote: > > + > > + if (nested) { > > + unsigned long max_map_size; > > + > > + max_map_size = force_pte ? PAGE_SIZE : PUD_SIZE; > > + > > + ipa = kvm_s2_trans_output(nested); > > + > > + /* > > + * If we're about to create a shadow stage 2 entry, then we > > + * can only create a block mapping if the guest stage 2 page > > + * table uses at least as big a mapping. > > + */ > > + max_map_size = min(kvm_s2_trans_size(nested), max_map_size); > > + > > + /* > > + * Be careful that if the mapping size falls between > > + * two host sizes, take the smallest of the two. > > + */ > > + if (max_map_size >= PMD_SIZE && max_map_size < PUD_SIZE) > > + max_map_size = PMD_SIZE; > > + else if (max_map_size >= PAGE_SIZE && max_map_size < PMD_SIZE) > > + max_map_size = PAGE_SIZE; > > + > > + force_pte = (max_map_size == PAGE_SIZE); > > + vma_pagesize = min(vma_pagesize, (long)max_map_size); > > + } > > + > > if (vma_pagesize == PMD_SIZE || vma_pagesize == PUD_SIZE) > > fault_ipa &= ~(vma_pagesize - 1); > > > > - gfn = fault_ipa >> PAGE_SHIFT; > > + gfn = ipa >> PAGE_SHIFT; > > I had seen a non-nested guest boot failure (with vma_pagesize == > PUD_SIZE) and bisection led me here. > > Is it intentional to ignore the fault_ipa adjustment when calculating > gfn if the guest memory is backed by hugetlbfs? This looks broken for > the non-nested case. > > But since I haven't looked at user_mem_abort() for a long time, I'm not > sure if I'd missed something... Nope, you're spot on as usual. Seems like we'd want to make sure both the canonical IPA and fault IPA are hugepage-aligned to get the right PFN and map it at the right place. I repro'ed the boot failure, the following diff gets me back in business. I was _just_ about to send the second batch of fixes, but this is a rather smelly one. Unless someone screams, this is getting stuffed on top. diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index 6981b1bc0946..a509b63bd4dd 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -1540,8 +1540,15 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, vma_pagesize = min(vma_pagesize, (long)max_map_size); } - if (vma_pagesize == PMD_SIZE || vma_pagesize == PUD_SIZE) + /* + * Both the canonical IPA and fault IPA must be hugepage-aligned to + * ensure we find the right PFN and lay down the mapping in the right + * place. + */ + if (vma_pagesize == PMD_SIZE || vma_pagesize == PUD_SIZE) { fault_ipa &= ~(vma_pagesize - 1); + ipa &= ~(vma_pagesize - 1); + } gfn = ipa >> PAGE_SHIFT; mte_allowed = kvm_vma_mte_allowed(vma); -- Thanks, Oliver