From patchwork Fri Jun 25 01:39:39 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12343463 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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 9BB29C49EA6 for ; Fri, 25 Jun 2021 01:39:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 50B93613B9 for ; Fri, 25 Jun 2021 01:39:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 50B93613B9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 613938D000D; Thu, 24 Jun 2021 21:39:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 59C728D0007; Thu, 24 Jun 2021 21:39:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 417268D000D; Thu, 24 Jun 2021 21:39:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id 0FF1C8D0007 for ; Thu, 24 Jun 2021 21:39:41 -0400 (EDT) Received: from smtpin37.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2FC8180B6074 for ; Fri, 25 Jun 2021 01:39:41 +0000 (UTC) X-FDA: 78290539362.37.84EDE8B Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf26.hostedemail.com (Postfix) with ESMTP id CBD254080F7B for ; Fri, 25 Jun 2021 01:39:40 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id A52AC60232; Fri, 25 Jun 2021 01:39:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1624585180; bh=jXQexAp7uCJqp7UJssXaInCjqk7jF5DIsxgf31ksxs8=; h=Date:From:To:Subject:In-Reply-To:From; b=hEyspiQfjaEySMWq2p/90vtL6U+KXDfwQ85OWBOqeaFRzTKAFdys1jkDZqsC7Bo70 bqOUu2wZOfePLhVL2jON9y8XkEtNw5KUjoNd77DcKw1tLBlJHX/vka/JflB+Z1BpJN YX564oTiOVoHAKwsHVK1gw9WTmNBwv5MaVJVIR8k= Date: Thu, 24 Jun 2021 18:39:39 -0700 From: Andrew Morton To: akpm@linux-foundation.org, borntraeger@de.ibm.com, catalin.marinas@arm.com, david@redhat.com, frankja@linux.ibm.com, hch@infradead.org, imbrenda@linux.ibm.com, linux-mm@kvack.org, mingo@redhat.com, mm-commits@vger.kernel.org, npiggin@gmail.com, rientjes@google.com, tglx@linutronix.de, torvalds@linux-foundation.org, urezki@gmail.com Subject: [patch 13/24] KVM: s390: prepare for hugepage vmalloc Message-ID: <20210625013939.606vJComT%akpm@linux-foundation.org> In-Reply-To: <20210624183838.ac3161ca4a43989665ac8b2f@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: CBD254080F7B X-Stat-Signature: 1k1zrri56o6a6ehew3auaruhtuebexc1 Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=hEyspiQf; dmarc=none; spf=pass (imf26.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1624585180-276782 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Claudio Imbrenda Subject: KVM: s390: prepare for hugepage vmalloc The Create Secure Configuration Ultravisor Call does not support using large pages for the virtual memory area. This is a hardware limitation. This patch replaces the vzalloc call with an almost equivalent call to the newly introduced vmalloc_no_huge function, which guarantees that only small pages will be used for the backing. The new call will not clear the allocated memory, but that has never been an actual requirement. Link: https://lkml.kernel.org/r/20210614132357.10202-3-imbrenda@linux.ibm.com Fixes: 121e6f3258fe3 ("mm/vmalloc: hugepage vmalloc mappings") Signed-off-by: Claudio Imbrenda Reviewed-by: Janosch Frank Acked-by: Christian Borntraeger Acked-by: Nicholas Piggin Reviewed-by: David Hildenbrand Cc: Nicholas Piggin Cc: Uladzislau Rezki (Sony) Cc: Catalin Marinas Cc: Thomas Gleixner Cc: Ingo Molnar Cc: David Rientjes Cc: Christoph Hellwig Signed-off-by: Andrew Morton --- arch/s390/kvm/pv.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/arch/s390/kvm/pv.c~kvm-s390-prepare-for-hugepage-vmalloc +++ a/arch/s390/kvm/pv.c @@ -140,7 +140,12 @@ static int kvm_s390_pv_alloc_vm(struct k /* Allocate variable storage */ vlen = ALIGN(virt * ((npages * PAGE_SIZE) / HPAGE_SIZE), PAGE_SIZE); vlen += uv_info.guest_virt_base_stor_len; - kvm->arch.pv.stor_var = vzalloc(vlen); + /* + * The Create Secure Configuration Ultravisor Call does not support + * using large pages for the virtual memory area. + * This is a hardware limitation. + */ + kvm->arch.pv.stor_var = vmalloc_no_huge(vlen); if (!kvm->arch.pv.stor_var) goto out_err; return 0;