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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2010CC4332F for ; Thu, 29 Dec 2022 17:44:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233873AbiL2RoA (ORCPT ); Thu, 29 Dec 2022 12:44:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229535AbiL2Rn7 (ORCPT ); Thu, 29 Dec 2022 12:43:59 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F321BF5C for ; Thu, 29 Dec 2022 09:43:58 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 339A3B81A1A for ; Thu, 29 Dec 2022 17:43:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C476EC433D2; Thu, 29 Dec 2022 17:43:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672335835; bh=0zUp+fYSboly8+3UmtFNqfIjlBnD7OkrbQa+vn0tC9s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DYvMWD2mjSmEIkjREzwavaZh0Ms4a2zNBTf7Y431IlU/3ynD+x87SMiXkjyfx45lV 18mfk3l8jUHNf8dIjbUyB4je0jTpZZ29jzkm8w90ga+bzF4jB2ragTbBwsmI5F7SFY WEOhDPHPrZspPMth73fNKyVIPo0Q6s5axvybLqJyutrQnPm91YkYIEuSJlQJJWrSY0 Sxy6aG86mMpSksNFNT1ggtkVKeXm1dOOWV6PQVAhUSgICcSUQSX6ux1E+ljArfA/Pj to8Mvx+ZhgM3NVRwS4d9H22aPDHneL9AtukY0sAfN8Du4bnMN7+V+ON4U6eQkhE5Cl 0E5YqjNVx6ISg== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pAwwb-00FkJB-Eb; Thu, 29 Dec 2022 17:43:53 +0000 Date: Thu, 29 Dec 2022 17:42:34 +0000 Message-ID: <87wn6ads39.wl-maz@kernel.org> From: Marc Zyngier To: Ganapatrao Kulkarni Cc: catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, scott@os.amperecomputing.com, keyur@os.amperecomputing.com Subject: Re: [PATCH 3/3] KVM: arm64: nv: Avoid block mapping if max_map_size is smaller than block size. In-Reply-To: <20220824060304.21128-4-gankulkarni@os.amperecomputing.com> References: <20220824060304.21128-1-gankulkarni@os.amperecomputing.com> <20220824060304.21128-4-gankulkarni@os.amperecomputing.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: gankulkarni@os.amperecomputing.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, scott@os.amperecomputing.com, keyur@os.amperecomputing.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 24 Aug 2022 07:03:04 +0100, Ganapatrao Kulkarni wrote: > > In NV case, Shadow stage 2 page table is created using host hypervisor > page table configuration like page size, block size etc. Also, the shadow > stage 2 table uses block level mapping if the Guest Hypervisor IPA is > backed by the THP pages. However, this is resulting in illegal mapping of > NestedVM IPA to Host Hypervisor PA, when Guest Hypervisor and Host > hypervisor are configured with different pagesize. > > Adding fix to avoid block level mapping in stage 2 mapping if > max_map_size is smaller than the block size. > > Signed-off-by: Ganapatrao Kulkarni > --- > arch/arm64/kvm/mmu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index 6caa48da1b2e..3d4b53f153a1 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -1304,7 +1304,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > * backed by a THP and thus use block mapping if possible. > */ > if (vma_pagesize == PAGE_SIZE && > - !(max_map_size == PAGE_SIZE || device)) { > + !(max_map_size < PMD_SIZE || device)) { > if (fault_status == FSC_PERM && fault_granule > PAGE_SIZE) > vma_pagesize = fault_granule; > else That's quite a nice catch. I guess this was the main issue with running 64kB L1 on a 4kB L0? Now, I'm not that fond of the fix itself, and I think max_map_size should always represent something that is a valid size *on the host*, specially when outside of NV-specific code. How about something like this instead: @@ -1346,6 +1346,11 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, * table uses at least as big a mapping. */ max_map_size = min(kvm_s2_trans_size(nested), max_map_size); + + 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; } vma_pagesize = min(vma_pagesize, max_map_size); Admittedly, this is a lot uglier than your fix. But it keep the nested horror localised, and doesn't risk being reverted by accident by people who would not take NV into account (can't blame them, really). Can you please give it a go? Thanks, M. -- Without deviation from the norm, progress is not possible.