From nobody Sun Feb 8 11:06:38 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 6DFDA14A092 for ; Wed, 3 Apr 2024 15:35:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712158513; cv=none; b=YorfNMyp7LvmfKX10qTstbXKA4xO/PE+2nx1qLJYExejgYYfmzRVZEZjijD36Prf0U3GfS0H/BSHIHrcrWcUqoShXSjvLIbd0kO1TffeuKwWHsXcfRHb76TbYoFWvao6HJc+nsJKRzwtg6DF7Mef7Isilc2chiOc9gf9KHXPaAg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712158513; c=relaxed/simple; bh=Wf5ddrRpRHX3prUPCD88r6sLOCPnyoEo7OA8sy+PQns=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=jiqrJ+SJ22bobAh9rx1vV8nEX9zmP8ejOcoi+/IrGnsJr+io0ViUX0eBMkyuf1XFoBc1skFjNKhchbvnCE90f38wvBuFlVduGA3gz7u1E1oWFBBBDsFaTwEgPEapHBJY/La83U4/AqTpmtFlPaxmG0MnbbhUXSZFkr4d900jaIE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=XDdjKJ85; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="XDdjKJ85" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712158512; x=1743694512; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=Wf5ddrRpRHX3prUPCD88r6sLOCPnyoEo7OA8sy+PQns=; b=XDdjKJ85hEOozy03Pvf/XKG058vvfFZYPN/Z1+YQyW8O3Zr8jgZuFS5E N245jumD+CrCmebqxcugA81DC9sjTAXtkeD/WpcfnwmR1EKEk2hIyYOJq Xsq2+3rflvelJT1IvIHUc/xbMTD4nOvrZZpswj3g/boKJramv+HVoXrZP lpkPvxBUvkQDwpLVMSkYAeWBuYQAcHp+Fg+8ISFCsBfR8Ev9bfCGIvOy6 is8AzUc6untKEzGIxVUj2phcVl9JZhsE1NH1jtFtOYNvnsj4sHaXtztmt 1PdrfBswNZj3gouARH2Vf1i72uy6N7M+WW6hroBct9X5lRlFPGaX23zJY Q==; X-CSE-ConnectionGUID: twQeUfEEQB6Jybg+szSfOQ== X-CSE-MsgGUID: OOTQoDZ5T/C8ls3JCy3/Tg== X-IronPort-AV: E=McAfee;i="6600,9927,11033"; a="18556316" X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="18556316" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 08:35:11 -0700 X-CSE-ConnectionGUID: JBZt3WQ2TC2kkRYVJPVCvA== X-CSE-MsgGUID: wm9S4QMZRLuWZebduMz0zg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="18395600" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by fmviesa010.fm.intel.com with ESMTP; 03 Apr 2024 08:35:10 -0700 Subject: [PATCH 1/4] x86/cpu: Add and use new CPUID region helper To: linux-kernel@vger.kernel.org Cc: jgross@suse.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen ,kai.huang@intel.com From: Dave Hansen Date: Wed, 03 Apr 2024 08:35:10 -0700 References: <20240403153508.7328E749@davehans-spike.ostc.intel.com> In-Reply-To: <20240403153508.7328E749@davehans-spike.ostc.intel.com> Message-Id: <20240403153510.F327603D@davehans-spike.ostc.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Dave Hansen There are some (before now) unwritten rules about CPUID "regions". Basically, there is a 32-bit address space of CPUID leaves. The top 16 bits address a "region" and the first leaf in a region is special. The kernel only has a few spots that care about this, but it's rather hard to make sense of the code as is. Add a helper that explains regions. Use it where applicable. Signed-off-by: Dave Hansen Reviewed-by: Kai Huang Cc: Juergen Gross -- changes from v1: * Fix typo comment and whitespace gunk noted by Ingo --- b/arch/x86/include/asm/cpuid.h | 59 +++++++++++++++++++++++++++++++++= +++++ b/arch/x86/kernel/cpu/common.c | 13 +++----- b/arch/x86/kernel/cpu/transmeta.c | 9 +---- b/arch/x86/xen/enlighten_pv.c | 9 +---- 4 files changed, 69 insertions(+), 21 deletions(-) diff -puN arch/x86/include/asm/cpuid.h~cpuid-regions arch/x86/include/asm/c= puid.h --- a/arch/x86/include/asm/cpuid.h~cpuid-regions 2024-04-02 15:22:58.838912= 075 -0700 +++ b/arch/x86/include/asm/cpuid.h 2024-04-02 15:22:58.846912085 -0700 @@ -168,4 +168,63 @@ static inline uint32_t hypervisor_cpuid_ return 0; } =20 +/* + * By convention, CPUID is broken up into regions which each + * have 2^16 leaves. EAX in the first leaf of each valid + * region returns the maximum valid leaf in that region. + * + * The regions can be thought of as being vendor-specific + * areas of CPUID, but that's imprecise because everybody + * implements the "Intel" region and Intel implements the + * AMD region. There are a few well-known regions: + * - Intel (0x0000) + * - AMD (0x8000) + * - Transmeta (0x8086) + * - Centaur (0xC000) + * + * Consider a CPU where the maximum leaf in the Transmeta + * region is 2. On such a CPU, leaf 0x80860000 would contain: + * EAX=3D=3D0x80860002. + * region-^^^^ + * max leaf-^^^^ + */ +static inline u32 cpuid_region_max_leaf(u16 region) +{ + u32 eax =3D cpuid_eax(region << 16); + + /* + * An unsupported region may return data from the last + * "basic" leaf, which is essentially garbage. Avoid + * mistaking basic leaf data for region data. + * + * Note: this is not perfect. It is theoretically + * possible for the last basic leaf to _resemble_ a + * valid first leaf from a region that doesn't exist. + * But Intel at least seems to pad out the basic region + * with 0's, possibly to avoid this. + */ + if ((eax >> 16) !=3D region) + return 0; + + return eax; +} + +/* Returns true if the leaf exists and @value was populated */ +static inline bool get_cpuid_region_leaf(u32 leaf, enum cpuid_regs_idx reg, + u32 *value) +{ + u16 region =3D leaf >> 16; + u32 regs[4]; + + if (cpuid_region_max_leaf(region) < leaf) + return false; + + cpuid(leaf, ®s[CPUID_EAX], ®s[CPUID_EBX], + ®s[CPUID_ECX], ®s[CPUID_EDX]); + + *value =3D regs[reg]; + + return true; +} + #endif /* _ASM_X86_CPUID_H */ diff -puN arch/x86/kernel/cpu/common.c~cpuid-regions arch/x86/kernel/cpu/co= mmon.c --- a/arch/x86/kernel/cpu/common.c~cpuid-regions 2024-04-02 15:22:58.842912= 079 -0700 +++ b/arch/x86/kernel/cpu/common.c 2024-04-02 15:22:58.846912085 -0700 @@ -1049,16 +1049,13 @@ void get_cpu_cap(struct cpuinfo_x86 *c) } =20 /* AMD-defined flags: level 0x80000001 */ - eax =3D cpuid_eax(0x80000000); - c->extended_cpuid_level =3D eax; + c->extended_cpuid_level =3D cpuid_region_max_leaf(0x8000); =20 - if ((eax & 0xffff0000) =3D=3D 0x80000000) { - if (eax >=3D 0x80000001) { - cpuid(0x80000001, &eax, &ebx, &ecx, &edx); + if (c->extended_cpuid_level >=3D 0x80000001) { + cpuid(0x80000001, &eax, &ebx, &ecx, &edx); =20 - c->x86_capability[CPUID_8000_0001_ECX] =3D ecx; - c->x86_capability[CPUID_8000_0001_EDX] =3D edx; - } + c->x86_capability[CPUID_8000_0001_ECX] =3D ecx; + c->x86_capability[CPUID_8000_0001_EDX] =3D edx; } =20 if (c->extended_cpuid_level >=3D 0x80000007) { diff -puN arch/x86/kernel/cpu/transmeta.c~cpuid-regions arch/x86/kernel/cpu= /transmeta.c --- a/arch/x86/kernel/cpu/transmeta.c~cpuid-regions 2024-04-02 15:22:58.842= 912079 -0700 +++ b/arch/x86/kernel/cpu/transmeta.c 2024-04-02 15:22:58.846912085 -0700 @@ -9,14 +9,9 @@ =20 static void early_init_transmeta(struct cpuinfo_x86 *c) { - u32 xlvl; - /* Transmeta-defined flags: level 0x80860001 */ - xlvl =3D cpuid_eax(0x80860000); - if ((xlvl & 0xffff0000) =3D=3D 0x80860000) { - if (xlvl >=3D 0x80860001) - c->x86_capability[CPUID_8086_0001_EDX] =3D cpuid_edx(0x80860001); - } + get_cpuid_region_leaf(0x80860001, CPUID_EDX, + &c->x86_capability[CPUID_8086_0001_EDX]); } =20 static void init_transmeta(struct cpuinfo_x86 *c) diff -puN arch/x86/xen/enlighten_pv.c~cpuid-regions arch/x86/xen/enlighten_= pv.c --- a/arch/x86/xen/enlighten_pv.c~cpuid-regions 2024-04-02 15:22:58.8429120= 79 -0700 +++ b/arch/x86/xen/enlighten_pv.c 2024-04-03 08:34:28.221534043 -0700 @@ -141,16 +141,13 @@ static void __init xen_set_mtrr_data(voi }; unsigned int reg; unsigned long mask; - uint32_t eax, width; + uint32_t width; static struct mtrr_var_range var[MTRR_MAX_VAR_RANGES] __initdata; =20 /* Get physical address width (only 64-bit cpus supported). */ width =3D 36; - eax =3D cpuid_eax(0x80000000); - if ((eax >> 16) =3D=3D 0x8000 && eax >=3D 0x80000008) { - eax =3D cpuid_eax(0x80000008); - width =3D eax & 0xff; - } + /* Will overwrite 'width' if available in CPUID: */ + get_cpuid_region_leaf(0x80000008, CPUID_EAX, &width); =20 for (reg =3D 0; reg < MTRR_MAX_VAR_RANGES; reg++) { op.u.read_memtype.reg =3D reg; _ From nobody Sun Feb 8 11:06:38 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 D50A814A4D2 for ; Wed, 3 Apr 2024 15:35:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712158514; cv=none; b=qMXHjW0agxeqFjmTZp371FoIjy50BQIgamJxFkncmF8MWPZPflDO20uRIEFpAWYa6qPcCVTpUm32iyQwZWnC+gnTtD3FqdPFRgwxQH0v81EQ6CHYy9rB7mdpPDDlVBdfvHc6oAPAS5nbQ4wcnuIO1+77toGpZ/uLZyc7aUIftgs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712158514; c=relaxed/simple; bh=pRQ8ZuMeNG77xydBJ2pbyG/Gah/4v+e/Ti98iEFoDos=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=RXjptmWMJDqBaie7NISYYsntZgnh94RDuJnP1D4QNMi+eYAEkH9tqVxX9cW9qxGGzpEkPk+UxqZem4Mq2rm9ZE2dnJS2nOoK3KIDyl950CkIAup5WgYdZzskmyXJP6lYkMyigkXRG81bqXTUtPSacuYJNZyV5uPtd8QW8hzpOLU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MAhq0+RG; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MAhq0+RG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712158513; x=1743694513; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=pRQ8ZuMeNG77xydBJ2pbyG/Gah/4v+e/Ti98iEFoDos=; b=MAhq0+RGq2fbgFb9wS56ML1LZ5hJ0+/DRp7O9qavPJYx7JFUVLB3x2Ak CjAN81IZYRPZtRq+vcjmgHpSTq332yGm+DnBost0ytBZlNH+WK/kz52lq lJVCz8JuAWhjGrVbXgXUPPeaC5rhfkGKRB8ZqzGjGavZavt4A6sMTHDt0 jje3RJwYDmei0W0yRF6LlBZO0K5dEkQfp1U1AQltN8DGsoxMXE71UQGyP qfcdsEI+Dd3tbu2m/Dt/CtZk0nWD3r2BfYp/GptVFPpAW5AKC1LnMQBL/ RQx+2of2O7biTWFMUz76ofLK9KDXTEnJTH0bk44uZcz16nyziCXHDvnoY A==; X-CSE-ConnectionGUID: BfeIgOi+Tu24Aurrn3gAgA== X-CSE-MsgGUID: +BBGhaW1Toyi4NNmunc0wA== X-IronPort-AV: E=McAfee;i="6600,9927,11033"; a="18556321" X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="18556321" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 08:35:12 -0700 X-CSE-ConnectionGUID: BO8SpLMqQK+kTvPsb+QeBQ== X-CSE-MsgGUID: nz+SPtROTNuoCsqGpiUpaA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="18395608" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by fmviesa010.fm.intel.com with ESMTP; 03 Apr 2024 08:35:12 -0700 Subject: [PATCH 2/4] perf/x86/ibs: Use CPUID region helper To: linux-kernel@vger.kernel.org Cc: jgross@suse.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Wed, 03 Apr 2024 08:35:11 -0700 References: <20240403153508.7328E749@davehans-spike.ostc.intel.com> In-Reply-To: <20240403153508.7328E749@davehans-spike.ostc.intel.com> Message-Id: <20240403153511.75CB9DA0@davehans-spike.ostc.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Dave Hansen IBS details are enumerated in an extended CPUID leaf. But the support has an open-coded CPUID region check. Use the new helper to trim down the code. Signed-off-by: Dave Hansen -- Note: this cleanup could take another form: if (boot_cpu_data->extended_cpuid_level >=3D IBS_CPUID_FEATURES) caps =3D cpuid_eax(IBS_CPUID_FEATURES); that would be one fewer CPUID invocations, but one more line of code. --- b/arch/x86/events/amd/ibs.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff -puN arch/x86/events/amd/ibs.c~ibs-region-helpers arch/x86/events/amd/= ibs.c --- a/arch/x86/events/amd/ibs.c~ibs-region-helpers 2024-04-02 15:22:59.2629= 12595 -0700 +++ b/arch/x86/events/amd/ibs.c 2024-04-02 15:22:59.262912595 -0700 @@ -1278,18 +1278,13 @@ static __init int perf_event_ibs_init(vo =20 static __init u32 __get_ibs_caps(void) { - u32 caps; - unsigned int max_level; + u32 caps =3D 0; =20 if (!boot_cpu_has(X86_FEATURE_IBS)) return 0; =20 - /* check IBS cpuid feature flags */ - max_level =3D cpuid_eax(0x80000000); - if (max_level < IBS_CPUID_FEATURES) - return IBS_CAPS_DEFAULT; + get_cpuid_region_leaf(IBS_CPUID_FEATURES, CPUID_EAX, &caps); =20 - caps =3D cpuid_eax(IBS_CPUID_FEATURES); if (!(caps & IBS_CAPS_AVAIL)) /* cpuid flags not valid */ return IBS_CAPS_DEFAULT; _ From nobody Sun Feb 8 11:06:38 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 0595514A603 for ; Wed, 3 Apr 2024 15:35:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712158515; cv=none; b=uRmd37nmxi8TS+SiWFPoroYR0X8K3oDLj/ixt5he6B4pOcr5mirzFSZxjucYi534awnjrJCxxT9X9cFLE6rrfQhn6d5Tx+BX3HcM9LijYZtSFbxuCaYwfFInV78JbHaekG+bL2VbXJBhcZjruX2Gboe+A1V9jR/c2ONCQMvmLZw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712158515; c=relaxed/simple; bh=a6HVtRXaQfY5q5OgOACYnReHMtv81k9BxmJgM8UFrro=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=ob4m/SJE4b4mr3W7APPTj/7FXADzHiC9FbFrlitMV+x9M9F+KFphZeeZjuL1OJkonT/vzd9p8B+yEjlseyq5eUORpBv2aQTrtrAe+wwN05CdYPfv0ZRcMqlKbloVna7QRFp3O7jo1OYU4QlW+AuZem3epLu5ult0mYXTtIRlsxk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=BVJOKVzF; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="BVJOKVzF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712158514; x=1743694514; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=a6HVtRXaQfY5q5OgOACYnReHMtv81k9BxmJgM8UFrro=; b=BVJOKVzFtfmOftSSK81mV7xXymMs18XWi7Ioc8XWWi9V5uQvvAys2b2l 3btOopFlUAMU6A+val7OHnUk8dFR2xmPj+MZhjleiMyomEZ+bhLAybZpA U6Tp2wzRWP4yw35T9Lh2P9J7pgRiJRFrIoH+USOajo9QL5QDpjc893V2I 1CxG8lbHtfCDcNq0FB04O8tGowWuBtx8ccv3cjVpt/Z13H5XzHPMW06Q7 RnpI57z1ZmKZIEoxfU+YYgBzjxv5Ea11BMCMY9UYjBZfPxPYnZppuLTtf mGqnxxG69MikkQog3iJTCCPmgwzmdlMsekdVyEoWnMJmYswYb5wGXtAeB A==; X-CSE-ConnectionGUID: Or0ew0lWQbqKsOASe4mhVA== X-CSE-MsgGUID: TTVEedUIRLWcUK+Y+XC3RQ== X-IronPort-AV: E=McAfee;i="6600,9927,11033"; a="18556328" X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="18556328" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 08:35:14 -0700 X-CSE-ConnectionGUID: tDe7EAcpQ46er0WJjWuvmw== X-CSE-MsgGUID: VOZi+z/ZRni8Qe08hOCDYw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="18395618" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by fmviesa010.fm.intel.com with ESMTP; 03 Apr 2024 08:35:13 -0700 Subject: [PATCH 3/4] x86/boot: Explicitly pass NX enabling status To: linux-kernel@vger.kernel.org Cc: jgross@suse.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen ,kai.huang@intel.com From: Dave Hansen Date: Wed, 03 Apr 2024 08:35:13 -0700 References: <20240403153508.7328E749@davehans-spike.ostc.intel.com> In-Reply-To: <20240403153508.7328E749@davehans-spike.ostc.intel.com> Message-Id: <20240403153513.76C52354@davehans-spike.ostc.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Dave Hansen The kernel sometimes needs to mask unsupported bits out of page table entries. It does that with a mask: '__supported_pte_mask'. That mask can obviously only contain the No-eXecute bit (_PAGE_NX) on hardware where NX is supported. x86_configure_nx() checks the boot CPU's NX support and adjusts the mask appropriately. But it doesn't check support directly. It uses the venerable 'boot_cpu_data' which is a software approximation of the actual CPU support. Unfortunately, Xen wants to set up '__supported_pte_mask' before 'boot_cpu_data' has been initialized. It hacks around this problem by repeating some of the 'boot_cpu_data' setup *just* for NX. Have x86_configure_nx() stop consulting 'boot_cpu_data' and move the NX detection to the caller. No functional change. That will come later. Signed-off-by: Dave Hansen Reviewed-by: Kai Huang Reviewed-by: Juergen Gross --- b/arch/x86/include/asm/proto.h | 2 +- b/arch/x86/kernel/setup.c | 6 +++--- b/arch/x86/xen/enlighten_pv.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff -puN arch/x86/include/asm/proto.h~x86_configure_nx-arg arch/x86/includ= e/asm/proto.h --- a/arch/x86/include/asm/proto.h~x86_configure_nx-arg 2024-04-02 15:22:59= .638913056 -0700 +++ b/arch/x86/include/asm/proto.h 2024-04-02 15:22:59.642913062 -0700 @@ -37,7 +37,7 @@ void entry_SYSRETL_compat_end(void); #define entry_SYSENTER_compat NULL #endif =20 -void x86_configure_nx(void); +void x86_configure_nx(bool nx_supported); =20 extern int reboot_force; =20 diff -puN arch/x86/kernel/setup.c~x86_configure_nx-arg arch/x86/kernel/setu= p.c --- a/arch/x86/kernel/setup.c~x86_configure_nx-arg 2024-04-02 15:22:59.6389= 13056 -0700 +++ b/arch/x86/kernel/setup.c 2024-04-02 15:22:59.642913062 -0700 @@ -687,9 +687,9 @@ dump_kernel_offset(struct notifier_block return 0; } =20 -void x86_configure_nx(void) +void x86_configure_nx(bool nx_supported) { - if (boot_cpu_has(X86_FEATURE_NX)) + if (nx_supported) __supported_pte_mask |=3D _PAGE_NX; else __supported_pte_mask &=3D ~_PAGE_NX; @@ -853,7 +853,7 @@ void __init setup_arch(char **cmdline_p) * whether hardware doesn't support NX (so that the early EHCI debug * console setup can safely call set_fixmap()). */ - x86_configure_nx(); + x86_configure_nx(boot_cpu_has(X86_FEATURE_NX)); =20 parse_early_param(); =20 diff -puN arch/x86/xen/enlighten_pv.c~x86_configure_nx-arg arch/x86/xen/enl= ighten_pv.c --- a/arch/x86/xen/enlighten_pv.c~x86_configure_nx-arg 2024-04-02 15:22:59.= 638913056 -0700 +++ b/arch/x86/xen/enlighten_pv.c 2024-04-02 15:22:59.642913062 -0700 @@ -1371,7 +1371,7 @@ asmlinkage __visible void __init xen_sta =20 /* Work out if we support NX */ get_cpu_cap(&boot_cpu_data); - x86_configure_nx(); + x86_configure_nx(boot_cpu_has(X86_FEATURE_NX)); =20 /* * Set up kernel GDT and segment registers, mainly so that _ From nobody Sun Feb 8 11:06:38 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 8B87D14A633 for ; Wed, 3 Apr 2024 15:35:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712158516; cv=none; b=tLxkZsuJYdpR41EJae+udhtqT9lQC41GYS+AgGL68J/WFHZuTPJg/o1XK5WHaEQatoZXx4PnPuCDnYxxPFSIxjBk2E3lbUatg1ljwGaruo9dpAzWy+7ZjzGJvemQsk5crr+cIZT2BuRB8FnelK9xQc2wqG4V9IR6oVW8UVRJo1M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712158516; c=relaxed/simple; bh=jx3tpS06rszZZiW1VietOfoJ84bc3y027wrDYFXoLwY=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=lvtCU6G6UuyCotnJqVH7ltKJQGKWEQgZYpFQNLVCrrJlExR7kofbVwxdT3hWGSUZRHXBKSvyFLrlqTZui3yN5HeBTKFswP/mMymAQGQXf1O+y73NW2AJSym983n/ahZORXJsbV0DZI+899xhTQ5uYrFCMBXiGujF6cW2P2FxPVo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Uca8iIjH; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Uca8iIjH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712158516; x=1743694516; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=jx3tpS06rszZZiW1VietOfoJ84bc3y027wrDYFXoLwY=; b=Uca8iIjHB75Oig6x65DyQNj4NxwcxIbkD1aTkMGLl6xMxddRxNq+LVTc M3TXRCOA+OOPnKLMc12VZzK9fw9nWjbQBjf4+7tHVNLFCCuwqgcsarsvM kQCxjNxvXnwzuy1oH96703+1YiBzPfogn8AUvlgWkEK+wiCn7HxyHVv8V kcUfo5H92Qx3Uqyirnjfck9vexEArVTNzOKZq85fKdWxCsHZg6eennGja DLLSL1zgb5ugzOgImCzZCC5lxkoXYV6YjKwkrFT1gupVtgMw9m5/ymO3a EBLaS9osHwvgx49c3P+p8vM6j6ZbpQIGtlqyGs8X4xeKav2O/FX1NLva1 Q==; X-CSE-ConnectionGUID: iOJCh39SSqydd8Qjps+50g== X-CSE-MsgGUID: jiWUzcnyRomnmpIUpvMlXg== X-IronPort-AV: E=McAfee;i="6600,9927,11033"; a="18556337" X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="18556337" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 08:35:16 -0700 X-CSE-ConnectionGUID: Thu+w43xRuqA0zm5vzEnJA== X-CSE-MsgGUID: Vl0FAN+tQle4/EU9X6zu8g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="18395625" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by fmviesa010.fm.intel.com with ESMTP; 03 Apr 2024 08:35:15 -0700 Subject: [PATCH 4/4] x86/xen: Enumerate NX from CPUID directly To: linux-kernel@vger.kernel.org Cc: jgross@suse.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Wed, 03 Apr 2024 08:35:14 -0700 References: <20240403153508.7328E749@davehans-spike.ostc.intel.com> In-Reply-To: <20240403153508.7328E749@davehans-spike.ostc.intel.com> Message-Id: <20240403153514.CC2C9D13@davehans-spike.ostc.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Dave Hansen xen_start_kernel() is some of the first C code run "Xen PV" systems. It precedes things like setup_arch() or processor initialization code that would be thought of as "very early". That means that 'boot_cpu_data' is garbage. It has not even established the utter basics like if the CPU supports the CPUID instruction. Unfortunately get_cpu_cap() requires this exact information. Nevertheless, xen_start_kernel() calls get_cpu_cap(). But it works out in practice because it's looking for the NX bit which comes from an extended CPUID leaf that doesn't depend on c->cpuid_level being set. Stop calling get_cpu_cap(). Use CPUID directly. Add a little helper to avoid cluttering up the xen_start_kernel() flow. This removes the risky, barely-working call to get_cpu_cap(). Note: The '& 31' strips the "capability" word off of an X86_FEATURE_* value. It's a magic number, but there are a few of them sparsely scattered around and it's way shorter than any helper. Signed-off-by: Dave Hansen Cc: Juergen Gross --- b/arch/x86/xen/enlighten_pv.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff -puN arch/x86/xen/enlighten_pv.c~xen-explain1 arch/x86/xen/enlighten_p= v.c --- a/arch/x86/xen/enlighten_pv.c~xen-explain1 2024-04-02 15:23:00.04691355= 7 -0700 +++ b/arch/x86/xen/enlighten_pv.c 2024-04-02 15:23:00.050913562 -0700 @@ -1306,6 +1306,21 @@ static void __init xen_domu_set_legacy_f =20 extern void early_xen_iret_patch(void); =20 +/* + * It is too early for boot_cpu_has() and friends to work. + * Use CPUID to directly enumerate NX support. + */ +static inline void xen_configure_nx(void) +{ + bool nx_supported; + u32 eax =3D 0; + + get_cpuid_region_leaf(0x80000001, CPUID_EDX, &eax); + + nx_supported =3D eax & (X86_FEATURE_NX & 31); + x86_configure_nx(nx_supported); +} + /* First C function to be called on Xen boot */ asmlinkage __visible void __init xen_start_kernel(struct start_info *si) { @@ -1369,9 +1384,7 @@ asmlinkage __visible void __init xen_sta /* Get mfn list */ xen_build_dynamic_phys_to_machine(); =20 - /* Work out if we support NX */ - get_cpu_cap(&boot_cpu_data); - x86_configure_nx(boot_cpu_has(X86_FEATURE_NX)); + xen_configure_nx(); =20 /* * Set up kernel GDT and segment registers, mainly so that _