From patchwork Wed Apr 5 11:09:05 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Suzuki K Poulose X-Patchwork-Id: 13201618 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 49C89C77B6C for ; Wed, 5 Apr 2023 11:10:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=kl8kDK0lpof8ECM2qbzD6edf+8KwPQExxn++ddxHchs=; b=MhqKkG/d57k/f5 RxbBOWOYg+Ei/il6XZDyAPSLzCDEfnfmH4ig68g+Ib3bjQddDZTVL3WboHSYRAYCQBWyFyZaiiVkM ONLkeK2aQLRko895I9NaaO6P2uDwJQfML/1BDFTetvkcjqBnjQTZNs2XCPT8qXf9pr8kFlAld/SrU SMflcpLXPVLbiuVZEe/O4QQTA0/MxJR99yEbsv6ywbE46cimalh7MAmDcz1MG3Er654+UXIHPmj8l lc2Xq8KAvTAwpYh8/5IKCjQyijTqcOgtXlKvBOQhAb3GK6kaiSsW7TenOm9i/wPs1B7G43NIMBKo9 M+DYFepcveh0u8sMZaXg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pk10u-004Cfw-1m; Wed, 05 Apr 2023 11:09:16 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pk10r-004CfW-1U for linux-arm-kernel@lists.infradead.org; Wed, 05 Apr 2023 11:09:15 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 75DD31684; Wed, 5 Apr 2023 04:09:55 -0700 (PDT) Received: from ewhatever.cambridge.arm.com (ewhatever.cambridge.arm.com [10.1.197.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 102193F73F; Wed, 5 Apr 2023 04:09:09 -0700 (PDT) From: Suzuki K Poulose To: will@kernel.org Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, alexandru.elisei@arm.com, maz@kernel.org, Suzuki K Poulose Subject: [PATCH] arm: Do not add padding alignment for hugetlbfs backed memory Date: Wed, 5 Apr 2023 12:09:05 +0100 Message-Id: <20230405110905.669217-1-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230405_040913_563460_A6E31905 X-CRM114-Status: GOOD ( 12.15 ) 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 The arm code tries to align the memory allocation size to 2M to potentially make use of the transparent hugepages. But this would be problematic if we try to allocate from the hugetlbfs, where the allocation size could be more than 2M. Given we support upto 1G, let use leave it to the user to align the requested memory when hugetlbfs is used. Without the patch: $ echo 1 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages $ mount -t hugetlbfs -o pagesize=1G none /root/hugemem/ $ lkvm run -m 1024 --hugetlbfs /root/hugemem/ ... # lkvm run -k ... -m 1024 -c 6 Fatal: Can't ftruncate for mem mapping size 1075838976 Signed-off-by: Suzuki K Poulose Acked-by: Marc Zyngier --- arm/kvm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arm/kvm.c b/arm/kvm.c index d51cc15d..9f958232 100644 --- a/arm/kvm.c +++ b/arm/kvm.c @@ -37,7 +37,9 @@ void kvm__init_ram(struct kvm *kvm) * 2M trumps 64K, so let's go with that. */ kvm->ram_size = kvm->cfg.ram_size; - kvm->arch.ram_alloc_size = kvm->ram_size + SZ_2M; + kvm->arch.ram_alloc_size = kvm->ram_size; + if (!kvm->cfg.hugetlbfs_path) + kvm->arch.ram_alloc_size += SZ_2M; kvm->arch.ram_alloc_start = mmap_anon_or_hugetlbfs(kvm, kvm->cfg.hugetlbfs_path, kvm->arch.ram_alloc_size);