From nobody Wed Feb 11 07:12:18 2026 Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6888FE552 for ; Mon, 20 May 2024 19:10:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.143.35 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716232228; cv=none; b=HGkPT+p9R+kEwmztWJTCmsJinIRGDR9D2Y5RRaCR77CQox1X3xjjpcIF7LlWExQGT919IMBXohVnEkbv1u7sWDSkPUJz6V/sL2c218lGlqT8Iw1ruCZ6n20boFDITD+T9Bz4HEhbq9XISzNruA9BHE52BnqMwU1V7ihpwEAILno= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716232228; c=relaxed/simple; bh=AMpZ/XE+XtDZfE0FuZLIM9BLqIRsVCI+b6KrxaoT1js=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=kzFsEtfcUnb0hpyraRljw5RrXaZrVLGUT0CyGO6PwRiCkDkHWWXW4sE9rtpP0uvPJuNJRL8pjCJ1yJcxyVnEVQ4kL9aNjFKFrUJsb+F2mvMhiz+MO4aKnk6fxIeezRIIxteUk6AkciVIsfr+zmxVfjcCoaj5S9oC+wDyTe9BCiY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=hpe.com; spf=pass smtp.mailfrom=hpe.com; dkim=pass (2048-bit key) header.d=hpe.com header.i=@hpe.com header.b=GoJrVK0Y; arc=none smtp.client-ip=148.163.143.35 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=hpe.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=hpe.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=hpe.com header.i=@hpe.com header.b="GoJrVK0Y" Received: from pps.filterd (m0134425.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 44KFWZME010874; Mon, 20 May 2024 18:36:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding; s=pps0720; bh=5wnYJKVBAgZHtm4apI+o0UClri+N/eR13sz7FUVRYjw=; b=GoJrVK0YAPbMJ++h0//zbHUPoyWODEUHcPq9LwYJRi8NoufXV5RRUUyR0YYDDIn9Lan7 B0Rp12H/84E6tuR+jrX8oirE0fj/esxTR4UU4zXmAxrI+zZnFSA+js2QUO7rjp8QuHL+ MA9Vo7e/08Mgcqh+jdxlHc7uWBbbeKKD/aSm9WWPWwYkKvG1PZeN8jhFdhOtMCJ8PdUP N5G9ikkJzPjIMqn+tIPU5FTC1We7X2OzwfDPSM+d99wKtMidUFArtZDrxf0SEhJgo0Rs ZTw74+eNscP+xivYPFMKmLjjzaN2r0zM5TRJsVo713xCOzHLD3sE1HyMQdFSnYOIqJ8B NQ== Received: from p1lg14880.it.hpe.com ([16.230.97.201]) by mx0b-002e3701.pphosted.com (PPS) with ESMTPS id 3y831p4x7x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 May 2024 18:36:41 +0000 Received: from p1lg14885.dc01.its.hpecorp.net (unknown [10.119.18.236]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by p1lg14880.it.hpe.com (Postfix) with ESMTPS id 776798005CD; Mon, 20 May 2024 18:36:39 +0000 (UTC) Received: from dog.eag.rdlabs.hpecorp.net (unknown [16.231.227.36]) by p1lg14885.dc01.its.hpecorp.net (Postfix) with ESMTP id 6AC5080476C; Mon, 20 May 2024 18:36:37 +0000 (UTC) Received: by dog.eag.rdlabs.hpecorp.net (Postfix, from userid 200934) id B26F630000BAA; Mon, 20 May 2024 13:36:33 -0500 (CDT) From: Steve Wahl To: Steve Wahl , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , linux-kernel@vger.kernel.org, Pavin Joseph , Eric Hagberg Cc: Simon Horman , Eric Biederman , Dave Young , Sarah Brofeldt , Russ Anderson , Dimitri Sivanich , Hou Wenlong , Andrew Morton , Baoquan He , Yuntao Wang , Bjorn Helgaas , Joerg Roedel , Michael Roth Subject: [PATCH 3/3] x86/mm/ident_map: Use gbpages only where full GB page should be mapped. Date: Mon, 20 May 2024 13:36:33 -0500 Message-Id: <20240520183633.1457687-4-steve.wahl@hpe.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20240520183633.1457687-1-steve.wahl@hpe.com> References: <20240520183633.1457687-1-steve.wahl@hpe.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Proofpoint-ORIG-GUID: kB2OdoC0ioKZxcX2bg6EmVmECzcjw9UW X-Proofpoint-GUID: kB2OdoC0ioKZxcX2bg6EmVmECzcjw9UW X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16 definitions=2024-05-20_09,2024-05-17_03,2024-05-17_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 malwarescore=0 clxscore=1015 adultscore=0 priorityscore=1501 phishscore=0 mlxscore=0 suspectscore=0 spamscore=0 lowpriorityscore=0 impostorscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2405010000 definitions=main-2405200149 Content-Type: text/plain; charset="utf-8" When ident_pud_init() uses only gbpages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. On UV systems, this ends up including regions that will cause hardware to halt the system if accessed (these are marked "reserved" by BIOS). Even processor speculation into these regions is enough to trigger the system halt. Only use gbpages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full gbpage. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence. Signed-off-by: Steve Wahl Tested-by: Pavin Joseph Tested-by: Sarah Brofeldt Tested-by: Eric Hagberg --- arch/x86/mm/ident_map.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/arch/x86/mm/ident_map.c b/arch/x86/mm/ident_map.c index 968d7005f4a7..a204a332c71f 100644 --- a/arch/x86/mm/ident_map.c +++ b/arch/x86/mm/ident_map.c @@ -26,18 +26,31 @@ static int ident_pud_init(struct x86_mapping_info *info= , pud_t *pud_page, for (; addr < end; addr =3D next) { pud_t *pud =3D pud_page + pud_index(addr); pmd_t *pmd; + bool use_gbpage; =20 next =3D (addr & PUD_MASK) + PUD_SIZE; if (next > end) next =3D end; =20 - if (info->direct_gbpages) { - pud_t pudval; + /* if this is already a gbpage, this portion is already mapped */ + if (pud_leaf(*pud)) + continue; + + /* Is using a gbpage allowed? */ + use_gbpage =3D info->direct_gbpages; =20 - if (pud_present(*pud)) - continue; + /* Don't use gbpage if it maps more than the requested region. */ + /* at the beginning: */ + use_gbpage &=3D ((addr & ~PUD_MASK) =3D=3D 0); + /* ... or at the end: */ + use_gbpage &=3D ((next & ~PUD_MASK) =3D=3D 0); + + /* Never overwrite existing mappings */ + use_gbpage &=3D !pud_present(*pud); + + if (use_gbpage) { + pud_t pudval; =20 - addr &=3D PUD_MASK; pudval =3D __pud((addr - info->offset) | info->page_flag); set_pud(pud, pudval); continue; --=20 2.26.2