Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3493362pxf; Mon, 29 Mar 2021 03:56:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCdmCHqCjJ/GDDMllpDlERVG5FEatdRcVEQS0xaMSzuxR8H6lgptvymJgUUE/V33p45RyO X-Received: by 2002:a17:906:a3d1:: with SMTP id ca17mr28016304ejb.92.1617015418126; Mon, 29 Mar 2021 03:56:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617015418; cv=none; d=google.com; s=arc-20160816; b=tu3HZynd7AkNMtQYpGlkim/vFG3mlroDDQngcWjMK47bcwYK3UQgR41ugDzl7GTVI2 +QPcFBKX3i41bOCpPIBbSFv0gqs8+ug0RxguI+UIfwoOfIJVdFOzXwS8M6oaT/uJH/KJ 3JSwUr/Xyfy8yxi7tLjXgZkrVODMv6TNSJ/JLs0wGcwyHbhEHAnVJd0qyRXekZolt5b7 T4O1llN3YH13Y5cYxgdTitgbLGyfVKYNWxZ7R2dFKfYogGxIxyG87hdcarzmjaRyyH9s 4+YQxuuIOmq7Nfa6lFrgTz2GKiR/IMxHTVcMfxOYsagUd36w/6mKLpl88JAk3Ik8Tc2M TgTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=lmVEX434yq31Z7iqaozmChqIW9IhCwE9/BtUdK9Z5bs=; b=irYomZ4qIWwTtw9g9aIHgohP1JWH4Ht+1OoC0UkraH8BdotMgON40CFqtUFtVVOBUJ d0VuSUcWfhnP3T5zXPCjIwxCMSRbsYdR8GT2IEAHBba9td2N9CoREdqwsYJUHhZMw35h O1xshDOeCD5IokalkmDW9XCTWUAeElRihRFD6oLFkF+QKZYkbmth7wOtxSAiHMZChyMR 516YP1gk32Lpjer8QpaBs9i5fA05I9EBZqYLXZUoPBeNV7+/duRzk6Jcoj7WobDcDRvG LghOnOOLrAis/+CTqTv7tZmdBTX3XpHKPValwGLyuOVBPfT6P33q3c5gz6EZjJoC5/oy KEVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=zqWFdDtQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y8si12811692eda.435.2021.03.29.03.56.36; Mon, 29 Mar 2021 03:56:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=zqWFdDtQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235357AbhC2IpJ (ORCPT + 99 others); Mon, 29 Mar 2021 04:45:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:42788 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234051AbhC2I1l (ORCPT ); Mon, 29 Mar 2021 04:27:41 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3554661932; Mon, 29 Mar 2021 08:26:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617006394; bh=/gQnNQRk1YgMl16NiS70nCo1pvUnpHlNXci7lYC3YBM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zqWFdDtQNMv7eWa30O4wBtsrDdLTDkXK17htdswfkRQQCRUJH35oGR57mVSBmXwAQ 9hmxSAUQ7wD0FcntoynuTOEuqEewpIJ1Qb5rKgUfmYsVOuafiSyzgGSbDpaSI9Lx6U kFt0ZOodPiESfb7CTVuHBY30NOuYkKhIcmPDiWVI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Boris Ostrovsky Subject: [PATCH 5.10 218/221] Revert "xen: fix p2m size in dom0 for disabled memory hotplug case" Date: Mon, 29 Mar 2021 09:59:09 +0200 Message-Id: <20210329075636.413839812@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210329075629.172032742@linuxfoundation.org> References: <20210329075629.172032742@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Roger Pau Monne commit af44a387e743ab7aa39d3fb5e29c0a973cf91bdc upstream. This partially reverts commit 882213990d32 ("xen: fix p2m size in dom0 for disabled memory hotplug case") There's no need to special case XEN_UNPOPULATED_ALLOC anymore in order to correctly size the p2m. The generic memory hotplug option has already been tied together with the Xen hotplug limit, so enabling memory hotplug should already trigger a properly sized p2m on Xen PV. Note that XEN_UNPOPULATED_ALLOC depends on ZONE_DEVICE which pulls in MEMORY_HOTPLUG. Leave the check added to __set_phys_to_machine and the adjusted comment about EXTRA_MEM_RATIO. Signed-off-by: Roger Pau Monné Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20210324122424.58685-3-roger.pau@citrix.com Signed-off-by: Greg Kroah-Hartman [boris: fixed formatting issues] Signed-off-by: Boris Ostrovsky --- arch/x86/include/asm/xen/page.h | 12 ------------ arch/x86/xen/p2m.c | 3 --- arch/x86/xen/setup.c | 16 ++++++++++++++-- 3 files changed, 14 insertions(+), 17 deletions(-) --- a/arch/x86/include/asm/xen/page.h +++ b/arch/x86/include/asm/xen/page.h @@ -87,18 +87,6 @@ clear_foreign_p2m_mapping(struct gnttab_ #endif /* - * The maximum amount of extra memory compared to the base size. The - * main scaling factor is the size of struct page. At extreme ratios - * of base:extra, all the base memory can be filled with page - * structures for the extra memory, leaving no space for anything - * else. - * - * 10x seems like a reasonable balance between scaling flexibility and - * leaving a practically usable system. - */ -#define XEN_EXTRA_MEM_RATIO (10) - -/* * Helper functions to write or read unsigned long values to/from * memory, when the access may fault. */ --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -416,9 +416,6 @@ void __init xen_vmalloc_p2m_tree(void) xen_p2m_last_pfn = xen_max_p2m_pfn; p2m_limit = (phys_addr_t)P2M_LIMIT * 1024 * 1024 * 1024 / PAGE_SIZE; - if (!p2m_limit && IS_ENABLED(CONFIG_XEN_UNPOPULATED_ALLOC)) - p2m_limit = xen_start_info->nr_pages * XEN_EXTRA_MEM_RATIO; - vm.flags = VM_ALLOC; vm.size = ALIGN(sizeof(unsigned long) * max(xen_max_p2m_pfn, p2m_limit), PMD_SIZE * PMDS_PER_MID_PAGE); --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -59,6 +59,18 @@ static struct { } xen_remap_buf __initdata __aligned(PAGE_SIZE); static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY; +/* + * The maximum amount of extra memory compared to the base size. The + * main scaling factor is the size of struct page. At extreme ratios + * of base:extra, all the base memory can be filled with page + * structures for the extra memory, leaving no space for anything + * else. + * + * 10x seems like a reasonable balance between scaling flexibility and + * leaving a practically usable system. + */ +#define EXTRA_MEM_RATIO (10) + static bool xen_512gb_limit __initdata = IS_ENABLED(CONFIG_XEN_512GB); static void __init xen_parse_512gb(void) @@ -778,13 +790,13 @@ char * __init xen_memory_setup(void) extra_pages += max_pages - max_pfn; /* - * Clamp the amount of extra memory to a XEN_EXTRA_MEM_RATIO + * Clamp the amount of extra memory to a EXTRA_MEM_RATIO * factor the base size. * * Make sure we have no memory above max_pages, as this area * isn't handled by the p2m management. */ - extra_pages = min3(XEN_EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), + extra_pages = min3(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)), extra_pages, max_pages - max_pfn); i = 0; addr = xen_e820_table.entries[0].addr;