From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 2A7B2548ED for ; Thu, 22 Feb 2024 18:39:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627170; cv=none; b=bABpUVqMg73kT7DkVDNodlyGsskPlQv3Koh5TQGpD6PkifKNpOACbo+RZ0gHwce7Dr03oQ5kdgif19zDV0pEUoU83cl/LSvJqf7pjIvfseTiwhShrUuXees/BTNbK8Rq3AwdOmToy++4M4Z593B87Z53PPQs6HPMDX+4Wx+1FbA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627170; c=relaxed/simple; bh=vgTVF3fDvGFxF4OBhUY/4q62vw94GJkPL24swZeT0Rw=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=uiYO2ngh0nBPTawwA28Cyw8xN71T352mV2WxZXEnAJnkNEHyqM70qgPr68HMNpYGgsXisKG/er2Nxm5DX3tf3C2IgfiybpiQ/+rHwjrmDO2y56ZdHHMw0hd+kYvrYFkJdepQHPQ3NuS5IizaIMEPngtYySYGWlmdvvwqZWOw4fc= 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=kioV02ZG; arc=none smtp.client-ip=198.175.65.16 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="kioV02ZG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627170; x=1740163170; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=vgTVF3fDvGFxF4OBhUY/4q62vw94GJkPL24swZeT0Rw=; b=kioV02ZGV65ayAoM4nTnR1ZSF9cn7W4dvS8gzf1jgffMd6HWsfQ+rjUB vlXCZzNePIKEG4JVeQxc0kpnRBrmT5X/w7Bt7x12lva9gYBhpKpjRhHQT fmAAyZedqG6NuPMTrm67I572kYhhcAACGtWo83xTfHKsBVTbCeX6Qs5Jl gEvv+2Fnu+Qs9aa8q/Lg562cNbQ4MZKipkNHI9dxF2UtzyONKjxp0pkfF uyph4b4rf7O66IWL6sShdSdosI1Gn8Diq+vjmveos9VmI7ZFs0XhsKZWx xaPjvGWAqUE/GANsJqHqsxReK2oxSdSJgi586YTFJ2ZTwnziBGixcKa06 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031679" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031679" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975353" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:29 -0800 Subject: [RFC][PATCH 01/34] x86/xen: Explain why calling get_cpu_cap() so early is a hack To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen ,jgross@suse.com From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:28 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183928.0D8942B2@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() some of the first C code run "Xen PV" systems. It precedes normally very early things like setup_arch() or the processor initialization code. 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. This also implicitly assumes that Xen PV guests support CPUID. Leave the hack in place, but at least explain some of what is going on. Signed-off-by: Dave Hansen Cc: Juergen Gross --- b/arch/x86/xen/enlighten_pv.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) 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-02-22 10:08:48.40445114= 6 -0800 +++ b/arch/x86/xen/enlighten_pv.c 2024-02-22 10:08:48.404451146 -0800 @@ -1372,7 +1372,11 @@ asmlinkage __visible void __init xen_sta /* Get mfn list */ xen_build_dynamic_phys_to_machine(); =20 - /* Work out if we support NX */ + /* + * This is a hack. 'boot_cpu_data' is not filled out enough + * for get_cpu_cap() to function fully. But it _can_ fill out + * the leaves where NX is. Gross, but it works. + */ get_cpu_cap(&boot_cpu_data); x86_configure_nx(); =20 _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 3765E548EA for ; Thu, 22 Feb 2024 18:39:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627171; cv=none; b=UcN9lLeTtZnPyt2R9Jhn+GLKTlKDOWXlnAlrFv2/eFeRSuHcR7Yod3G84Lm5fC1SIGlqEWZweVAeJ+D3eRf+MjXzSDf/kSLbam2j5hnmqGcvMva+KUUgsBGMXEfVd3/Ro04kI9Z39kSRFc/oNQsPbglrcM0aXbNbqjPaMBYd8nA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627171; c=relaxed/simple; bh=BPPylVdwVb0qsjnFOdjrkJjwVsPFVOkQjGFT9BiJDoA=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=bGtf2uxpZI+m2mQf0LvOZA4rbU131H1YrbCTxl5/kvP/ZUsWfCKOJ0/H86asBrsJ8gKXaqbcUTFDy2s/D2KEmEpEVnXu8mxKa+bmSw9RHp/bA9LS0qOCBUqoBKrbC9NxDBV6QV3P+ytmM3dlGoDc+plzjtGhA2uvd6AKo87qZ2E= 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=CoSQBoF7; arc=none smtp.client-ip=198.175.65.16 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="CoSQBoF7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627171; x=1740163171; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=BPPylVdwVb0qsjnFOdjrkJjwVsPFVOkQjGFT9BiJDoA=; b=CoSQBoF7OJhhgetU9+kqSkODrwERp43kUg8OpMLShjc2ue8GPE4+3Bwj bZzh6ERdae+jQiCZnTppWst0keM/wcCPO4LxFnLS6E1Uun7RF79fT03PJ feQPrpt7T1CBZnDN73UeBzJoInMFRJGLG+gE3+kOC0WTRI0g33UDEkZCm gkNXlfRPEEeyCyoMBHWjMdkaJSIKVBR9BX8/P+HFPNSydE6PwcSCEWPDc X2t4qy1gyA9/oXlv4bwRXwqs1s6ufCslEy4KrHF2kyYDpdUq9c6VOA7VE EyZTveECGEwNCNz+sIdQ9rBa6IuCLymiEt/WfueV8gOkJY2qftlAvH/oh Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031690" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031690" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:30 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975371" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:30 -0800 Subject: [RFC][PATCH 02/34] x86/xen: Remove early "debug" physical address lookups To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen ,jgross@suse.com From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:29 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183929.E17C1B9C@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 __pa() facility is subject to debugging checks if CONFIG_DEBUG_VIRTUAL= =3Dy. One of those debugging checks is whether the physical address is valid on the platform. That information is normally available via CPUID. But the __pa() code currently looks it up in 'boot_cpu_data' which is not fully set up in early Xen PV boot. The Xen PV code currently tries to get this info with get_cpu_address_sizes() which also depends on 'boot_cpu_data' to be at least somewhat set up. The result is that the c->x86_phys_bits gets a sane value, but not one that has anything to do with the hardware. In other words, the CONFIG_DEBUG_VIRTUAL checks are performed with what amounts to garbage inputs. Garbage checks are worse than no check at all. Move over to the "nodebug" variant to axe the checks. Signed-off-by: Dave Hansen Cc: Juergen Gross Reviewed-by: Borislav Petkov (AMD) Reviewed-by: Juergen Gross --- b/arch/x86/xen/enlighten_pv.c | 2 +- b/arch/x86/xen/mmu_pv.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff -puN arch/x86/xen/enlighten_pv.c~xen-no-early-__pa arch/x86/xen/enligh= ten_pv.c --- a/arch/x86/xen/enlighten_pv.c~xen-no-early-__pa 2024-02-22 10:08:48.868= 469363 -0800 +++ b/arch/x86/xen/enlighten_pv.c 2024-02-22 10:08:48.872469519 -0800 @@ -1452,7 +1452,7 @@ asmlinkage __visible void __init xen_sta boot_params.hdr.type_of_loader =3D (9 << 4) | 0; boot_params.hdr.ramdisk_image =3D initrd_start; boot_params.hdr.ramdisk_size =3D xen_start_info->mod_len; - boot_params.hdr.cmd_line_ptr =3D __pa(xen_start_info->cmd_line); + boot_params.hdr.cmd_line_ptr =3D __pa_nodebug(xen_start_info->cmd_line); boot_params.hdr.hardware_subarch =3D X86_SUBARCH_XEN; =20 if (!xen_initial_domain()) { diff -puN arch/x86/xen/mmu_pv.c~xen-no-early-__pa arch/x86/xen/mmu_pv.c --- a/arch/x86/xen/mmu_pv.c~xen-no-early-__pa 2024-02-22 10:08:48.872469519= -0800 +++ b/arch/x86/xen/mmu_pv.c 2024-02-22 10:08:48.872469519 -0800 @@ -2006,7 +2006,7 @@ void __init xen_reserve_special_pages(vo { phys_addr_t paddr; =20 - memblock_reserve(__pa(xen_start_info), PAGE_SIZE); + memblock_reserve(__pa_nodebug(xen_start_info), PAGE_SIZE); if (xen_start_info->store_mfn) { paddr =3D PFN_PHYS(mfn_to_pfn(xen_start_info->store_mfn)); memblock_reserve(paddr, PAGE_SIZE); _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 1B126548FF for ; Thu, 22 Feb 2024 18:39:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627172; cv=none; b=P2Fu7thFCNcO0Bs1kjTNS9v/BgfUZD+EWc+to3cQeKmA6jVD5kuukbw2a0tZNVdqWSbgq9WlNo4o94/dlKJS0SVz+6/PIcHz+30Kagy0OyVRoBp3wyWt6S9NTp6RE83ZKji5bRgdO3mk/YKmwG761r95NqRUKhgr5QcXmPIJmUI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627172; c=relaxed/simple; bh=reS7y9hoRcSiyLDxW0i1cvzSnB6X77odpIXVmZj0hO4=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=qkAYQ4ivATkMts+FGPm2koNvE72OMD/hOG6w8Szyb037WZEF/lWPIWa66lBf81pRJntNoLF0has93vETaJP9l1xaUbeIiE9mD8lfwsCQjpgA+sv7asMpXyrsj1qGx9TVLUfgJPlDsEpxmxcwzl9SEgoZYcy2nWwvPKDxzUbLbAY= 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=SJgXYgLr; arc=none smtp.client-ip=198.175.65.16 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="SJgXYgLr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627172; x=1740163172; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=reS7y9hoRcSiyLDxW0i1cvzSnB6X77odpIXVmZj0hO4=; b=SJgXYgLr8wewQQzMBKjs0KtCdD2lgB3k/CIaNQ0Uk4+sHaRVK2n6zi1x 2cIeOsCmCKs3uQSBfprkfFMpASEGDbD/VrLogRUbZltUzGnyh5X8qA1DO Z6UtJ+3xiIxSIfeP8qtdcWoWb1kMJZ3xo0ZbM16ZeY2bfg6AEMt2Tzn7n uOx8OxnWYDRCxy6FP3gtnVIiWf4gpr/RDWq7jqtC6E8PfLrDZngdEpNkx cyu0ek6jCFvKU+5Up2Sfc7WzV4KzU5c/4Awcxv9elkIv3e7vZSMw5/1Oa N6nv/UJZ50z8zPw1k75rV6/ge3Xq/DhEoxqGZTGxPh9fe78uuvyNSstsf Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031700" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031700" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975391" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:31 -0800 Subject: [RFC][PATCH 03/34] x86/pci: Assume that clflush size is always provided To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:30 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183930.18D74E8B@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 early boot code always sets _some_ clflush size. Use that fact to avoid handling the case where it is not set. There may have been a time when the Xen PV call in here way too early. But it calls get_cpu_address_sizes() before calling here now. It should also be safe. Note: This series will eventually return sane defaults even very early in boot. I believe this is safe now, but it becomes *really* safe later on. Signed-off-by: Dave Hansen Reviewed-by: Borislav Petkov (AMD) --- b/arch/x86/pci/common.c | 19 +++---------------- 1 file changed, 3 insertions(+), 16 deletions(-) diff -puN arch/x86/pci/common.c~x86-pci-clflush-size arch/x86/pci/common.c --- a/arch/x86/pci/common.c~x86-pci-clflush-size 2024-02-22 10:08:49.356488= 521 -0800 +++ b/arch/x86/pci/common.c 2024-02-22 10:08:49.356488521 -0800 @@ -480,22 +480,9 @@ void pcibios_scan_root(int busnum) =20 void __init pcibios_set_cache_line_size(void) { - struct cpuinfo_x86 *c =3D &boot_cpu_data; - - /* - * Set PCI cacheline size to that of the CPU if the CPU has reported it. - * (For older CPUs that don't support cpuid, we se it to 32 bytes - * It's also good for 386/486s (which actually have 16) - * as quite a few PCI devices do not support smaller values. - */ - if (c->x86_clflush_size > 0) { - pci_dfl_cache_line_size =3D c->x86_clflush_size >> 2; - printk(KERN_DEBUG "PCI: pci_cache_line_size set to %d bytes\n", - pci_dfl_cache_line_size << 2); - } else { - pci_dfl_cache_line_size =3D 32 >> 2; - printk(KERN_DEBUG "PCI: Unknown cacheline size. Setting to 32 bytes\n"); - } + pci_dfl_cache_line_size =3D boot_cpu_data.x86_clflush_size >> 2; + printk(KERN_DEBUG "PCI: pci_cache_line_size set to %d bytes\n", + pci_dfl_cache_line_size << 2); } =20 int __init pcibios_init(void) _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 752B75491F for ; Thu, 22 Feb 2024 18:39:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627174; cv=none; b=QxPEs85q9EpBGIaTs/5KlZPvaQq1wBAN32gF4QHKPYLho1lg22GhDofqkpuCrkiRLaJ9bl9cgo6cP08P5EOSH914jIs2mDrFkX1kyFNJDA2LE0k8TGuqQ0N7NLs4NsHH+AcfoqIck1/YcqLBwr/lVUJzNquP2YDzXvLcRYDFq+s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627174; c=relaxed/simple; bh=Eq7jdEpOQPVSjCTiWMZuECRIdQ2sytlAHMnF66rSgXg=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=KETBFbQ2p7jMta/YonlGByl610M0IPLTuxPGJgcisFrPLyvKUX+b4JyJ/smvqzOC7+LaSWWh6enljd8X/TkxbNGr/f98rxvdF8/M6kKN1lfMnCQySbQo0Sm8wVDFg47xbe0djBjSD4bw5RTUmo/7Q1n2ZMd7KN26HySlQ5c7kZ0= 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=A5zMDDeZ; arc=none smtp.client-ip=198.175.65.16 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="A5zMDDeZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627173; x=1740163173; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=Eq7jdEpOQPVSjCTiWMZuECRIdQ2sytlAHMnF66rSgXg=; b=A5zMDDeZe0jTgkhBbUKTduHKty3FQiyfrZF4boZxqVn3g1cSkVwZiVE7 yEyTy3dji8hqujLi9NlAKwNhZ9AbrKnfBsec8R4rYFOHzg/a2qYpLTUji AHRoxzNhhN7vsa3qpOnHDvrOGlurOUDqyicIK2awmXqnZILmmruePHe+T negVrqAx0hVMhivdTyy8ykiJbL6Jq9AzR9av8sNEqnTMR8c6xVYdI50YR F5Uy0d08iCs9gKo4gpDpLB2A8Tl6n6GvXu0SyliKEl8Bm/iWe86RSoK8Y zmqpqGsZFlCOQhDPgIwcpEEBgZBrISFxPxWZ5yfzz6GcQdBfgN9FxeD8w A==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031708" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031708" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975401" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:32 -0800 Subject: [RFC][PATCH 04/34] x86/mm: Introduce physical address limit helper To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen ,rafael@kernel.org,lenb@kernel.org From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:32 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183932.244390AC@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 Modern processors enumerate the sizes of the physical and virtual address spaces that they can handle. The kernel stashes this information for each CPU in 'cpuinfo_x86'. Like a lot of system-wide configuration, in practice the kernel only uses this information from the boot CPU. That makes a lot of sense because the kernel can't practically support two CPUs with such different fundamental support as the size of the address spaces. Having a per-cpu copy of this data is silly. It is, at best, a waste of space to keep it around for the non-boot CPUs. At worst, it is yet another bit of data that must be initialized in a particular order and can be a source of bugs. Introduce a helper to look up the number of supported physical address bits: x86_phys_bits() Replace most open-coded references to boot_cpu_data.x86_phys_bits. This form is more compact and also opens up the door to adding some centralized checking and enforcing rules around this important system- wide value. Signed-off-by: Dave Hansen Cc: "Rafael J. Wysocki" Cc: Len Brown Reviewed-by: Kai Huang --- b/arch/x86/include/asm/kmsan.h | 2 +- b/arch/x86/include/asm/mce.h | 2 +- b/arch/x86/include/asm/processor.h | 5 +++++ b/arch/x86/kernel/cpu/mtrr/cleanup.c | 2 +- b/arch/x86/kernel/cpu/mtrr/generic.c | 2 +- b/arch/x86/kernel/cpu/mtrr/mtrr.c | 5 ++--- b/arch/x86/kernel/setup.c | 2 +- b/arch/x86/kvm/cpuid.c | 2 +- b/arch/x86/kvm/mmu.h | 10 +++++----- b/arch/x86/kvm/mmu/spte.c | 2 +- b/arch/x86/kvm/svm/svm.c | 2 +- b/arch/x86/kvm/vmx/vmx.c | 10 +++++----- b/arch/x86/kvm/vmx/vmx.h | 2 +- b/arch/x86/mm/physaddr.h | 2 +- b/drivers/acpi/acpi_fpdt.c | 2 +- 15 files changed, 28 insertions(+), 24 deletions(-) diff -puN arch/x86/include/asm/kmsan.h~introduce-x86_phys_bits arch/x86/inc= lude/asm/kmsan.h --- a/arch/x86/include/asm/kmsan.h~introduce-x86_phys_bits 2024-02-22 10:08= :49.828507052 -0800 +++ b/arch/x86/include/asm/kmsan.h 2024-02-22 10:08:49.852507994 -0800 @@ -52,7 +52,7 @@ static inline void *arch_kmsan_get_meta_ static inline bool kmsan_phys_addr_valid(unsigned long addr) { if (IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT)) - return !(addr >> boot_cpu_data.x86_phys_bits); + return !(addr >> x86_phys_bits()); else return true; } diff -puN arch/x86/include/asm/mce.h~introduce-x86_phys_bits arch/x86/inclu= de/asm/mce.h --- a/arch/x86/include/asm/mce.h~introduce-x86_phys_bits 2024-02-22 10:08:4= 9.828507052 -0800 +++ b/arch/x86/include/asm/mce.h 2024-02-22 10:08:49.852507994 -0800 @@ -89,7 +89,7 @@ #define MCI_MISC_ADDR_GENERIC 7 /* generic */ =20 /* MCi_ADDR register defines */ -#define MCI_ADDR_PHYSADDR GENMASK_ULL(boot_cpu_data.x86_phys_bits - 1, 0) +#define MCI_ADDR_PHYSADDR GENMASK_ULL(x86_phys_bits() - 1, 0) =20 /* CTL2 register defines */ #define MCI_CTL2_CMCI_EN BIT_ULL(30) diff -puN arch/x86/include/asm/processor.h~introduce-x86_phys_bits arch/x86= /include/asm/processor.h --- a/arch/x86/include/asm/processor.h~introduce-x86_phys_bits 2024-02-22 1= 0:08:49.828507052 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:08:49.852507994 -0800 @@ -767,4 +767,9 @@ static inline void weak_wrmsr_fence(void alternative("mfence; lfence", "", ALT_NOT(X86_FEATURE_APIC_MSRS_FENCE)); } =20 +static inline u8 x86_phys_bits(void) +{ + return boot_cpu_data.x86_phys_bits; +} + #endif /* _ASM_X86_PROCESSOR_H */ diff -puN arch/x86/kernel/cpu/mtrr/cleanup.c~introduce-x86_phys_bits arch/x= 86/kernel/cpu/mtrr/cleanup.c --- a/arch/x86/kernel/cpu/mtrr/cleanup.c~introduce-x86_phys_bits 2024-02-22= 10:08:49.832507209 -0800 +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c 2024-02-22 10:08:49.852507994 -0800 @@ -170,7 +170,7 @@ set_var_mtrr(unsigned int reg, unsigned return; } =20 - mask =3D (1ULL << boot_cpu_data.x86_phys_bits) - 1; + mask =3D (1ULL << x86_phys_bits()) - 1; mask &=3D ~((((u64)sizek) << 10) - 1); =20 base =3D ((u64)basek) << 10; diff -puN arch/x86/kernel/cpu/mtrr/generic.c~introduce-x86_phys_bits arch/x= 86/kernel/cpu/mtrr/generic.c --- a/arch/x86/kernel/cpu/mtrr/generic.c~introduce-x86_phys_bits 2024-02-22= 10:08:49.832507209 -0800 +++ b/arch/x86/kernel/cpu/mtrr/generic.c 2024-02-22 10:08:49.852507994 -0800 @@ -660,7 +660,7 @@ static void __init print_mtrr_state(void } pr_info("MTRR variable ranges %sabled:\n", mtrr_state.enabled & MTRR_STATE_MTRR_ENABLED ? "en" : "dis"); - high_width =3D (boot_cpu_data.x86_phys_bits - (32 - PAGE_SHIFT) + 3) / 4; + high_width =3D (x86_phys_bits() - (32 - PAGE_SHIFT) + 3) / 4; =20 for (i =3D 0; i < num_var_ranges; ++i) { if (mtrr_state.var_ranges[i].mask_lo & MTRR_PHYSMASK_V) diff -puN arch/x86/kernel/cpu/mtrr/mtrr.c~introduce-x86_phys_bits arch/x86/= kernel/cpu/mtrr/mtrr.c --- a/arch/x86/kernel/cpu/mtrr/mtrr.c~introduce-x86_phys_bits 2024-02-22 10= :08:49.836507366 -0800 +++ b/arch/x86/kernel/cpu/mtrr/mtrr.c 2024-02-22 10:08:49.852507994 -0800 @@ -252,8 +252,7 @@ int mtrr_add_page(unsigned long base, un return -EINVAL; } =20 - if ((base | (base + size - 1)) >> - (boot_cpu_data.x86_phys_bits - PAGE_SHIFT)) { + if ((base | (base + size - 1)) >> (x86_phys_bits() - PAGE_SHIFT)) { pr_warn("base or size exceeds the MTRR width\n"); return -EINVAL; } @@ -556,7 +555,7 @@ void __init mtrr_bp_init(void) const char *why =3D "(not available)"; unsigned long config, dummy; =20 - phys_hi_rsvd =3D GENMASK(31, boot_cpu_data.x86_phys_bits - 32); + phys_hi_rsvd =3D GENMASK(31, x86_phys_bits() - 32); =20 if (!generic_mtrrs && mtrr_state.enabled) { /* diff -puN arch/x86/kernel/setup.c~introduce-x86_phys_bits arch/x86/kernel/s= etup.c --- a/arch/x86/kernel/setup.c~introduce-x86_phys_bits 2024-02-22 10:08:49.8= 36507366 -0800 +++ b/arch/x86/kernel/setup.c 2024-02-22 10:08:49.852507994 -0800 @@ -813,7 +813,7 @@ void __init setup_arch(char **cmdline_p) */ early_reserve_memory(); =20 - iomem_resource.end =3D (1ULL << boot_cpu_data.x86_phys_bits) - 1; + iomem_resource.end =3D (1ULL << x86_phys_bits()) - 1; e820__memory_setup(); parse_setup_data(); =20 diff -puN arch/x86/kvm/cpuid.c~introduce-x86_phys_bits arch/x86/kvm/cpuid.c --- a/arch/x86/kvm/cpuid.c~introduce-x86_phys_bits 2024-02-22 10:08:49.8365= 07366 -0800 +++ b/arch/x86/kvm/cpuid.c 2024-02-22 10:08:49.852507994 -0800 @@ -1236,7 +1236,7 @@ static inline int __do_cpuid_func(struct * the HPAs do not affect GPAs. */ if (!tdp_enabled) - g_phys_as =3D boot_cpu_data.x86_phys_bits; + g_phys_as =3D x86_phys_bits(); else if (!g_phys_as) g_phys_as =3D phys_as; =20 diff -puN arch/x86/kvm/mmu.h~introduce-x86_phys_bits arch/x86/kvm/mmu.h --- a/arch/x86/kvm/mmu.h~introduce-x86_phys_bits 2024-02-22 10:08:49.840507= 523 -0800 +++ b/arch/x86/kvm/mmu.h 2024-02-22 10:08:49.852507994 -0800 @@ -84,10 +84,10 @@ static inline gfn_t kvm_mmu_max_gfn(void static inline u8 kvm_get_shadow_phys_bits(void) { /* - * boot_cpu_data.x86_phys_bits is reduced when MKTME or SME are detected - * in CPU detection code, but the processor treats those reduced bits as - * 'keyID' thus they are not reserved bits. Therefore KVM needs to look at - * the physical address bits reported by CPUID. + * x86_phys_bits() is reduced when MKTME or SME are detected in CPU + * detection code, but the processor treats those reduced bits as 'keyID' + * thus they are not reserved bits. Therefore KVM needs to look at the + * physical address bits reported by CPUID. */ if (likely(boot_cpu_data.extended_cpuid_level >=3D 0x80000008)) return cpuid_eax(0x80000008) & 0xff; @@ -97,7 +97,7 @@ static inline u8 kvm_get_shadow_phys_bit * custom CPUID. Proceed with whatever the kernel found since these feat= ures * aren't virtualizable (SME/SEV also require CPUIDs higher than 0x800000= 08). */ - return boot_cpu_data.x86_phys_bits; + return x86_phys_bits(); } =20 void kvm_mmu_set_mmio_spte_mask(u64 mmio_value, u64 mmio_mask, u64 access_= mask); diff -puN arch/x86/kvm/mmu/spte.c~introduce-x86_phys_bits arch/x86/kvm/mmu/= spte.c --- a/arch/x86/kvm/mmu/spte.c~introduce-x86_phys_bits 2024-02-22 10:08:49.8= 40507523 -0800 +++ b/arch/x86/kvm/mmu/spte.c 2024-02-22 10:08:49.852507994 -0800 @@ -468,7 +468,7 @@ void kvm_mmu_reset_all_pte_masks(void) * the most significant bits of legal physical address space. */ shadow_nonpresent_or_rsvd_mask =3D 0; - low_phys_bits =3D boot_cpu_data.x86_phys_bits; + low_phys_bits =3D x86_phys_bits(); if (boot_cpu_has_bug(X86_BUG_L1TF) && !WARN_ON_ONCE(boot_cpu_data.x86_cache_bits >=3D 52 - SHADOW_NONPRESENT_OR_RSVD_MASK_LEN)) { diff -puN arch/x86/kvm/svm/svm.c~introduce-x86_phys_bits arch/x86/kvm/svm/s= vm.c --- a/arch/x86/kvm/svm/svm.c~introduce-x86_phys_bits 2024-02-22 10:08:49.84= 0507523 -0800 +++ b/arch/x86/kvm/svm/svm.c 2024-02-22 10:08:49.852507994 -0800 @@ -5054,7 +5054,7 @@ static __init void svm_adjust_mmio_mask( return; =20 enc_bit =3D cpuid_ebx(0x8000001f) & 0x3f; - mask_bit =3D boot_cpu_data.x86_phys_bits; + mask_bit =3D x86_phys_bits(); =20 /* Increment the mask bit if it is the same as the encryption bit */ if (enc_bit =3D=3D mask_bit) diff -puN arch/x86/kvm/vmx/vmx.c~introduce-x86_phys_bits arch/x86/kvm/vmx/v= mx.c --- a/arch/x86/kvm/vmx/vmx.c~introduce-x86_phys_bits 2024-02-22 10:08:49.84= 4507680 -0800 +++ b/arch/x86/kvm/vmx/vmx.c 2024-02-22 10:08:49.852507994 -0800 @@ -8444,14 +8444,14 @@ static void __init vmx_setup_me_spte_mas * kvm_get_shadow_phys_bits() returns shadow_phys_bits. Use * the former to avoid exposing shadow_phys_bits. * - * On pre-MKTME system, boot_cpu_data.x86_phys_bits equals to + * On pre-MKTME system, x86_phys_bits() equals to * shadow_phys_bits. On MKTME and/or TDX capable systems, - * boot_cpu_data.x86_phys_bits holds the actual physical address - * w/o the KeyID bits, and shadow_phys_bits equals to MAXPHYADDR + * x86_phys_bits() holds the actual physical address w/o the + * KeyID bits, and shadow_phys_bits equals to MAXPHYADDR * reported by CPUID. Those bits between are KeyID bits. */ - if (boot_cpu_data.x86_phys_bits !=3D kvm_get_shadow_phys_bits()) - me_mask =3D rsvd_bits(boot_cpu_data.x86_phys_bits, + if (x86_phys_bits() !=3D kvm_get_shadow_phys_bits()) + me_mask =3D rsvd_bits(x86_phys_bits(), kvm_get_shadow_phys_bits() - 1); /* * Unlike SME, host kernel doesn't support setting up any diff -puN arch/x86/kvm/vmx/vmx.h~introduce-x86_phys_bits arch/x86/kvm/vmx/v= mx.h --- a/arch/x86/kvm/vmx/vmx.h~introduce-x86_phys_bits 2024-02-22 10:08:49.84= 4507680 -0800 +++ b/arch/x86/kvm/vmx/vmx.h 2024-02-22 10:08:49.852507994 -0800 @@ -721,7 +721,7 @@ static inline bool vmx_need_pf_intercept if (!enable_ept) return true; =20 - return allow_smaller_maxphyaddr && cpuid_maxphyaddr(vcpu) < boot_cpu_data= .x86_phys_bits; + return allow_smaller_maxphyaddr && cpuid_maxphyaddr(vcpu) < x86_phys_bits= (); } =20 static inline bool is_unrestricted_guest(struct kvm_vcpu *vcpu) diff -puN arch/x86/mm/physaddr.h~introduce-x86_phys_bits arch/x86/mm/physad= dr.h --- a/arch/x86/mm/physaddr.h~introduce-x86_phys_bits 2024-02-22 10:08:49.84= 8507837 -0800 +++ b/arch/x86/mm/physaddr.h 2024-02-22 10:08:49.852507994 -0800 @@ -4,7 +4,7 @@ static inline int phys_addr_valid(resource_size_t addr) { #ifdef CONFIG_PHYS_ADDR_T_64BIT - return !(addr >> boot_cpu_data.x86_phys_bits); + return !(addr >> x86_phys_bits()); #else return 1; #endif diff -puN drivers/acpi/acpi_fpdt.c~introduce-x86_phys_bits drivers/acpi/acp= i_fpdt.c --- a/drivers/acpi/acpi_fpdt.c~introduce-x86_phys_bits 2024-02-22 10:08:49.= 848507837 -0800 +++ b/drivers/acpi/acpi_fpdt.c 2024-02-22 10:08:49.852507994 -0800 @@ -151,7 +151,7 @@ static bool fpdt_address_valid(u64 addre * On some systems the table contains invalid addresses * with unsuppored high address bits set, check for this. */ - return !(address >> boot_cpu_data.x86_phys_bits); + return !(address >> x86_phys_bits()); } #else static bool fpdt_address_valid(u64 address) _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 ADD816AFAA for ; Thu, 22 Feb 2024 18:39:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627175; cv=none; b=Bl83jQofFexjUd+mMP0iZsx8Ls/47PAuXK7lSr4idH0pu8yQZYlwP8+Wn6gdJiNt554hvj19jSjG+bnMgGS8vwq/Wt+6PRzegwxEq5PFpC/E8npTCFh9vnjAvZpxaokZ5L4EmMBpk4aaNZS36buuSo4TUl6QArTQ3WDxcFovuKU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627175; c=relaxed/simple; bh=X3vgXtdWjBUY02JYo3ZQjlayem/luTu4o10k7E40aB4=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=dNYWqd2LqRb+XLiEs+6la4XBil+ehH34lWW+jpJXEGnj8TJTFaJ1p9LypkxAznOjPSozs1U8pel+599cxG7EsFBLkN1uAJUVUayDxv4DtlH8sYZazZviKnIa+GvWGPkJ3+WmVKCft/USXW3zBcdtD3xZodw+4cG2H1OC3eNyDUM= 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=Z4S1+zlp; arc=none smtp.client-ip=198.175.65.16 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="Z4S1+zlp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627174; x=1740163174; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=X3vgXtdWjBUY02JYo3ZQjlayem/luTu4o10k7E40aB4=; b=Z4S1+zlpZZOg/0Gv+EfBiTMWjbrP2W7s4zbrNcIQHr/cBPyV9VVocmw4 Mby7WOVDoz7BqdjV1p7GfjkGgP2Al/hvLSKnCvvAMsNP5xeGEWv7wZgch dPl6+W+3HT4LmEtnO2LE0uys2BlYQDnGBrMAjXundvxfz00SSCx1l4TaA vpwmodebCuzDJAYZp1JmqLll1Uv4q1V3UWZkUwG6RsHNyzW7hhVeWyzfw NepY7uj2WeTz/DFYtveaNAJrQxVIey2zm1VwJPUTmWR3kICssj2PDBqHE xFMTtHjNAq0YdHJvj13Y/lE3qG0nKLP6rxh3frSCg3zs95fumjSVI4fmL g==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031716" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031716" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975409" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:34 -0800 Subject: [RFC][PATCH 05/34] x86/cpu: Move /proc per-cpu ->x86_phys_bits reference to global one To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:33 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183933.953C8BFF@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 This is one of the few references to the per-cpu version of ->x86_phys_bits. It is theoretically possible to have this value vary from CPU to CPU. But in practice nobody builds systems that way. Continue outputting the value in /proc, but read it from the global configuration. Signed-off-by: Dave Hansen Reviewed-by: Kai Huang --- b/arch/x86/kernel/cpu/proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN arch/x86/kernel/cpu/proc.c~proc-global-x86-phys-bits arch/x86/ker= nel/cpu/proc.c --- a/arch/x86/kernel/cpu/proc.c~proc-global-x86-phys-bits 2024-02-22 10:08= :50.584536732 -0800 +++ b/arch/x86/kernel/cpu/proc.c 2024-02-22 10:08:50.584536732 -0800 @@ -133,7 +133,7 @@ static int show_cpuinfo(struct seq_file seq_printf(m, "clflush size\t: %u\n", c->x86_clflush_size); seq_printf(m, "cache_alignment\t: %d\n", c->x86_cache_alignment); seq_printf(m, "address sizes\t: %u bits physical, %u bits virtual\n", - c->x86_phys_bits, c->x86_virt_bits); + x86_phys_bits(), c->x86_virt_bits); =20 seq_puts(m, "power management:"); for (i =3D 0; i < 32; i++) { _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 037756E5E3 for ; Thu, 22 Feb 2024 18:39:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627176; cv=none; b=EJByfHpXvFq4ZoCLaMf3jlGl0ERJFa6tc8kMWuFs17vx+wO+zQ7Ab58XUvDhNCyexPLavd417PSJIbhjUujYLvAf8AZn8bboQKg39+YpK0o4uhKxbnDt9Uk/KtrSSNCpmxLqw3FcCNuE8lqmd9ppuOQFQXaCV/PDiNrLmTs+vj0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627176; c=relaxed/simple; bh=54nIGzcSRinqh/gqJc7uUClCQgBTJWKE3mQsU0/+39M=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=fvrdzLhdJZTO6jj8xSvbltKq+qA1GOEjn+eOmkdi1hgCyAKag5Z4YBd0HabzTKJtz9XgUymS23PkL4neQppP1nFXcnOoF1mazF117I1E48YX7A3ADB4KxOD0FH6wGBkgH/ZkubXSLXR1ClQFKmsXyKWE0/ClgLLp7p9dzIvYJ7g= 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=e26LNNjI; arc=none smtp.client-ip=198.175.65.16 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="e26LNNjI" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627176; x=1740163176; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=54nIGzcSRinqh/gqJc7uUClCQgBTJWKE3mQsU0/+39M=; b=e26LNNjIBucQIGmtd40DA59i5VO6rMeLqwpUdRVtLEqAcVk4h3KEUoKX 7/qXVXRWaUbAeFqBhgFXYN2s2SQbmmhqrPuisuMVwinW8gWtQIIiNS/Xw zoQzCmLz60IUhow8JGGjQi+ZzBwEj0OYSCucAg5/lO2ghX0+rH0biNAYx ++lLPRpXkqW7f9jkdjX/BC9k+aPxn48XjUZm6bdWQ3eIqKZZJ7jRxBo04 5QX47wookAWHn5DbMS+uEHzOurH7zDC4Y+COENVWbY4kKvtP44X2PYK1v awI1U3pPOqUCPU5tdklGAjDrfATC2V9pXPBu7TKSgmhkHTUuXnvYWsmnb A==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031723" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031723" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975421" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:35 -0800 Subject: [RFC][PATCH 06/34] x86/boot: Use consistent value for iomem_resource.end To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:34 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183934.033178B5@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 'struct cpuinfo_x86' values (including 'boot_cpu_info') get written and overwritten rather randomly. They are not stable during early boot and readers end up getting a random mishmash of hard-coded defaults or CPUID-provided values based on when the values are read. iomem_resource.end is one of these users. Because of where it is called, it ended up seeing .x86_phys_bits=3D=3DMAX_PHYSMEM_BITS which is (mostly) a compile-time default. But iomem_resource.end is never updated if the runtime CPUID .x86_phys_bits is lower. Set iomem_resource.end to the compile-time value explicitly. It does not need to be precise as this is mostly to ensure that insane values can't be reserved in 'iomem_resource'. Make MAX_PHYSMEM_BITS available outside of sparsemem configurations by removing the #ifdef CONFIG_SPARSEMEM in the header. Signed-off-by: Dave Hansen --- b/arch/x86/include/asm/sparsemem.h | 3 --- b/arch/x86/kernel/setup.c | 10 +++++++++- 2 files changed, 9 insertions(+), 4 deletions(-) diff -puN arch/x86/kernel/setup.c~iomem_resource_end arch/x86/kernel/setup.c --- a/arch/x86/kernel/setup.c~iomem_resource_end 2024-02-22 10:08:51.048554= 948 -0800 +++ b/arch/x86/kernel/setup.c 2024-02-22 10:21:04.485531464 -0800 @@ -51,6 +51,7 @@ #include #include #include +#include #include #include #include @@ -813,7 +814,14 @@ void __init setup_arch(char **cmdline_p) */ early_reserve_memory(); =20 - iomem_resource.end =3D (1ULL << x86_phys_bits()) - 1; + /* + * This was too big before. It ended up getting MAX_PHYSMEM_BITS + * even if .x86_phys_bits was eventually lowered below that. + * But that was evidently harmless, so leave it too big, but + * set it explicitly to MAX_PHYSMEM_BITS instead of taking a + * trip through .x86_phys_bits. + */ + iomem_resource.end =3D (1ULL << MAX_PHYSMEM_BITS) - 1; e820__memory_setup(); parse_setup_data(); =20 diff -puN arch/x86/include/asm/sparsemem.h~iomem_resource_end arch/x86/incl= ude/asm/sparsemem.h --- a/arch/x86/include/asm/sparsemem.h~iomem_resource_end 2024-02-22 10:19:= 56.842831828 -0800 +++ b/arch/x86/include/asm/sparsemem.h 2024-02-22 10:20:21.207804806 -0800 @@ -4,7 +4,6 @@ =20 #include =20 -#ifdef CONFIG_SPARSEMEM /* * generic non-linear memory support: * @@ -29,8 +28,6 @@ # define MAX_PHYSMEM_BITS (pgtable_l5_enabled() ? 52 : 46) #endif =20 -#endif /* CONFIG_SPARSEMEM */ - #ifndef __ASSEMBLY__ #ifdef CONFIG_NUMA_KEEP_MEMINFO extern int phys_to_target_node(phys_addr_t start); _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 60E606E602 for ; Thu, 22 Feb 2024 18:39:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627177; cv=none; b=ASX0WDKAg7yNFTAknFuPZKoIRCPUWLU5fBqOqwQZksOaUMpxMnZBfLTnJ4rPjNAusZeUoasFMOmQqTkuRztMabXHo54mP9lA+kQONXLMV4WF/jPorsshArlTsW8qcgqiYfBhFRtWlWd3kq+VInPwuGcebH+ajCQFMhKoXmOD1zA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627177; c=relaxed/simple; bh=rsFsu/cEO8uggTXoV412vUNfouqZDj34S3bAyQtscUc=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=jTY/9Or5H0HIYybA9OVQz6cdlvq0x0pZESwjEln83xSNwc3Pa1drn7PAyKMdfgd9KKfgj2qUP7Fef03RsooZUjqd/bBi2z/GXaBhd/MdvVYlJC2E67OidUsj1EaENaGmXhLvFOpvRizKXkkyFMhgXGZwvG4ZbJzpDZIAJ9DQQlo= 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=Ke59vf46; arc=none smtp.client-ip=198.175.65.16 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="Ke59vf46" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627177; x=1740163177; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=rsFsu/cEO8uggTXoV412vUNfouqZDj34S3bAyQtscUc=; b=Ke59vf46hCB8/Y38lI5g097MW0ExmetfvzN+yayXeJDw+ExuaFCmtA+a 2CVic5l2rgqi1jjqEpQ/UXsJ1/QjDs9zMmpmLugFbPBoGLm6iMOoCUuGx QNIdhD40uLuHiNutswp4JRz4xdxYDn8I2vEnEteiAMao1Z3cMx+dS+myA qLzter1YHNvOMtPNNTPEKZgDedbv5rU1G1FMAiLXGA8VBI0Xoq0pMMw+F cEbdByQdPgzNC2242FqU6lDPG9LxGWiDnoN0h1VoT3C5n5EltrjfufeeZ lmEquCaAQQq63ar959dzgeu2dwr/H1HePyFWhv9QdQgJ91GK2Va93KqHr A==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031733" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031733" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975440" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:36 -0800 Subject: [RFC][PATCH 07/34] x86/mm: Introduce virtual address space limit helper To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:35 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183935.286751FF@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 This uses the same logic and approach which were used for the physical address limits with x86_phys_bits() and extends them to the virtual address space. Introduce a system-wide helper for users to query the size of the virtual address space: x86_virt_bits() Signed-off-by: Dave Hansen Reviewed-by: Kai Huang --- b/arch/x86/events/amd/brs.c | 2 +- b/arch/x86/events/amd/lbr.c | 2 +- b/arch/x86/events/intel/pt.c | 4 ++-- b/arch/x86/include/asm/processor.h | 5 +++++ b/arch/x86/kernel/cpu/proc.c | 2 +- b/arch/x86/mm/maccess.c | 4 ++-- 6 files changed, 12 insertions(+), 7 deletions(-) diff -puN arch/x86/events/amd/brs.c~x86_virt_bits-func arch/x86/events/amd/= brs.c --- a/arch/x86/events/amd/brs.c~x86_virt_bits-func 2024-02-22 10:08:51.5285= 73793 -0800 +++ b/arch/x86/events/amd/brs.c 2024-02-22 10:08:51.536574107 -0800 @@ -285,7 +285,7 @@ void amd_brs_drain(void) struct perf_branch_entry *br =3D cpuc->lbr_entries; union amd_debug_extn_cfg cfg; u32 i, nr =3D 0, num, tos, start; - u32 shift =3D 64 - boot_cpu_data.x86_virt_bits; + u32 shift =3D 64 - x86_virt_bits(); =20 /* * BRS event forced on PMC0, diff -puN arch/x86/events/amd/lbr.c~x86_virt_bits-func arch/x86/events/amd/= lbr.c --- a/arch/x86/events/amd/lbr.c~x86_virt_bits-func 2024-02-22 10:08:51.5285= 73793 -0800 +++ b/arch/x86/events/amd/lbr.c 2024-02-22 10:08:51.536574107 -0800 @@ -89,7 +89,7 @@ static __always_inline u64 amd_pmu_lbr_g =20 static __always_inline u64 sign_ext_branch_ip(u64 ip) { - u32 shift =3D 64 - boot_cpu_data.x86_virt_bits; + u32 shift =3D 64 - x86_virt_bits(); =20 return (u64)(((s64)ip << shift) >> shift); } diff -puN arch/x86/events/intel/pt.c~x86_virt_bits-func arch/x86/events/int= el/pt.c --- a/arch/x86/events/intel/pt.c~x86_virt_bits-func 2024-02-22 10:08:51.528= 573793 -0800 +++ b/arch/x86/events/intel/pt.c 2024-02-22 10:08:51.536574107 -0800 @@ -1453,8 +1453,8 @@ static void pt_event_addr_filters_sync(s * canonical addresses does not affect the result of the * address filter. */ - msr_a =3D clamp_to_ge_canonical_addr(a, boot_cpu_data.x86_virt_bits); - msr_b =3D clamp_to_le_canonical_addr(b, boot_cpu_data.x86_virt_bits); + msr_a =3D clamp_to_ge_canonical_addr(a, x86_virt_bits()); + msr_b =3D clamp_to_le_canonical_addr(b, x86_virt_bits()); if (msr_b < msr_a) msr_a =3D msr_b =3D 0; } diff -puN arch/x86/include/asm/processor.h~x86_virt_bits-func arch/x86/incl= ude/asm/processor.h --- a/arch/x86/include/asm/processor.h~x86_virt_bits-func 2024-02-22 10:08:= 51.532573950 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:08:51.536574107 -0800 @@ -772,4 +772,9 @@ static inline u8 x86_phys_bits(void) return boot_cpu_data.x86_phys_bits; } =20 +static inline u8 x86_virt_bits(void) +{ + return boot_cpu_data.x86_virt_bits; +} + #endif /* _ASM_X86_PROCESSOR_H */ diff -puN arch/x86/kernel/cpu/proc.c~x86_virt_bits-func arch/x86/kernel/cpu= /proc.c --- a/arch/x86/kernel/cpu/proc.c~x86_virt_bits-func 2024-02-22 10:08:51.532= 573950 -0800 +++ b/arch/x86/kernel/cpu/proc.c 2024-02-22 10:08:51.536574107 -0800 @@ -133,7 +133,7 @@ static int show_cpuinfo(struct seq_file seq_printf(m, "clflush size\t: %u\n", c->x86_clflush_size); seq_printf(m, "cache_alignment\t: %d\n", c->x86_cache_alignment); seq_printf(m, "address sizes\t: %u bits physical, %u bits virtual\n", - x86_phys_bits(), c->x86_virt_bits); + x86_phys_bits(), x86_virt_bits()); =20 seq_puts(m, "power management:"); for (i =3D 0; i < 32; i++) { diff -puN arch/x86/mm/maccess.c~x86_virt_bits-func arch/x86/mm/maccess.c --- a/arch/x86/mm/maccess.c~x86_virt_bits-func 2024-02-22 10:08:51.53657410= 7 -0800 +++ b/arch/x86/mm/maccess.c 2024-02-22 10:08:51.536574107 -0800 @@ -20,10 +20,10 @@ bool copy_from_kernel_nofault_allowed(co * is initialized. Needed for instruction decoding in early * exception handlers. */ - if (!boot_cpu_data.x86_virt_bits) + if (!x86_virt_bits()) return true; =20 - return __is_canonical_address(vaddr, boot_cpu_data.x86_virt_bits); + return __is_canonical_address(vaddr, x86_virt_bits()); } #else bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size) _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 D376C71723 for ; Thu, 22 Feb 2024 18:39:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627179; cv=none; b=SNYL5o5CdHIGuLnV6nUC2bKFF+8WER8LQ6R36mRQL1PJtJSzy0U41NNiu1rh7rFmb3ZEqSQ1ajTiOiJDxhQcD2utKX6ram7mEJn9TN9w3UmtEyGBEcTj5QIqLD8FuagnkfQ05jJ1uXR30/MZ+B3kNls1iaaPg7bzIJArMtHVoho= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627179; c=relaxed/simple; bh=FehiVN43cGB3SSoJx1cXrEiiDX6N9eHmUXCTLrFRaO0=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=emSJuXnHwJAKV0ww6/jEd7+jv3WwIUYjm5W0YDL7yslvgU2Z+dnpv9nQlHYEgi3iqyykXo5Y0xPR4CjksMd+yO1Ruzm+GPkRXfbdH/DloVywnUUejxpktDXBQKk1JWlTxy+0kxo2Pefb+D4EPan1k4yQYPeaKiwjpepQI3UQun0= 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=TXxrxi6B; arc=none smtp.client-ip=198.175.65.16 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="TXxrxi6B" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627178; x=1740163178; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=FehiVN43cGB3SSoJx1cXrEiiDX6N9eHmUXCTLrFRaO0=; b=TXxrxi6BjZglHKehqF+m8955WqvXb0uM5B55OnensW87eGncEtbFEt4T EyPMWxeKS1Wm6uLWspC2ut2t5KL1r+8yP+gArjh3EdQM/Vdi8Amer8h9Q blgzC2aonYN9GjpfAMQXmu/yq7n7JCDcilrCq2xAX4GyjDmR7Slbp36MS rmbdTFQVj4zlzldtgMuPFDdZWInnuNa46AKzYbzcV+5VOmPLFMz2ACPfF 3rYIq3G8fOEN7vou64GXgKn0F+E2WYS30n54LAzFEdrv9NPXKp6HgeAOx OZaboVJhIalez8sLXzO8n5OgsKR9rAL6Bzkv38MkEkkp0d9K3rXGRQNzt A==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031742" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031742" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975454" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:38 -0800 Subject: [RFC][PATCH 08/34] x86/cpu: Add CLFLUSH size helper To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen ,mpatocka@redhat.com,snitzer@redhat.com,daniel@ffwll.ch From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:37 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183937.981D71D9@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 This is probably starting to look familiar: The size of a cacheline is fundamental system-wide information. Keeping it per-cpu is just silly. Introduce a system-wide helper for looking up the cacheline size and use it. This does one slightly odd looking thing, it stops setting c->x86_clflush_size on all but the boot CPU. This is functionally OK because all readers of the secondary CPU values also go away. It also makes it explicit that the 'boot_cpu_data' is the one true system-wide value. Signed-off-by: Dave Hansen Cc: Mikulas Patocka Cc: Mike Snitzer Cc: Daniel Vetter --- b/arch/x86/include/asm/processor.h | 5 +++++ b/arch/x86/kernel/cpu/centaur.c | 2 +- b/arch/x86/kernel/cpu/common.c | 9 +++++---- b/arch/x86/kernel/cpu/intel.c | 2 +- b/arch/x86/kernel/cpu/proc.c | 2 +- b/arch/x86/lib/usercopy_64.c | 7 +++---- b/arch/x86/mm/pat/set_memory.c | 2 +- b/arch/x86/pci/common.c | 2 +- b/drivers/gpu/drm/drm_cache.c | 4 ++-- b/drivers/gpu/drm/i915/i915_cmd_parser.c | 3 +-- b/drivers/gpu/drm/i915/i915_gem.c | 2 +- b/drivers/md/dm-writecache.c | 2 +- 12 files changed, 23 insertions(+), 19 deletions(-) diff -puN arch/x86/include/asm/processor.h~x86_clflush_size-func arch/x86/i= nclude/asm/processor.h --- a/arch/x86/include/asm/processor.h~x86_clflush_size-func 2024-02-22 10:= 08:52.112596720 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:08:52.132597505 -0800 @@ -777,4 +777,9 @@ static inline u8 x86_virt_bits(void) return boot_cpu_data.x86_virt_bits; } =20 +static inline u8 x86_clflush_size(void) +{ + return boot_cpu_data.x86_clflush_size; +} + #endif /* _ASM_X86_PROCESSOR_H */ diff -puN arch/x86/kernel/cpu/centaur.c~x86_clflush_size-func arch/x86/kern= el/cpu/centaur.c --- a/arch/x86/kernel/cpu/centaur.c~x86_clflush_size-func 2024-02-22 10:08:= 52.112596720 -0800 +++ b/arch/x86/kernel/cpu/centaur.c 2024-02-22 10:08:52.132597505 -0800 @@ -62,7 +62,7 @@ static void init_c3(struct cpuinfo_x86 * set_cpu_cap(c, X86_FEATURE_3DNOW); #endif if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) { - c->x86_cache_alignment =3D c->x86_clflush_size * 2; + c->x86_cache_alignment =3D x86_clflush_size() * 2; set_cpu_cap(c, X86_FEATURE_REP_GOOD); } =20 diff -puN arch/x86/kernel/cpu/common.c~x86_clflush_size-func arch/x86/kerne= l/cpu/common.c --- a/arch/x86/kernel/cpu/common.c~x86_clflush_size-func 2024-02-22 10:08:5= 2.112596720 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:08:52.132597505 -0800 @@ -954,8 +954,9 @@ void cpu_detect(struct cpuinfo_x86 *c) c->x86_stepping =3D x86_stepping(tfms); =20 if (cap0 & (1<<19)) { - c->x86_clflush_size =3D ((misc >> 8) & 0xff) * 8; - c->x86_cache_alignment =3D c->x86_clflush_size; + if (c =3D=3D &boot_cpu_data) + c->x86_clflush_size =3D ((misc >> 8) & 0xff) * 8; + c->x86_cache_alignment =3D x86_clflush_size(); } } } @@ -1123,7 +1124,7 @@ void get_cpu_address_sizes(struct cpuinf } } c->x86_cache_bits =3D c->x86_phys_bits; - c->x86_cache_alignment =3D c->x86_clflush_size; + c->x86_cache_alignment =3D x86_clflush_size(); } =20 static void identify_cpu_without_cpuid(struct cpuinfo_x86 *c) @@ -1831,7 +1832,7 @@ static void identify_cpu(struct cpuinfo_ c->x86_phys_bits =3D 32; c->x86_virt_bits =3D 32; #endif - c->x86_cache_alignment =3D c->x86_clflush_size; + c->x86_cache_alignment =3D x86_clflush_size(); memset(&c->x86_capability, 0, sizeof(c->x86_capability)); #ifdef CONFIG_X86_VMX_FEATURE_NAMES memset(&c->vmx_capability, 0, sizeof(c->vmx_capability)); diff -puN arch/x86/kernel/cpu/intel.c~x86_clflush_size-func arch/x86/kernel= /cpu/intel.c --- a/arch/x86/kernel/cpu/intel.c~x86_clflush_size-func 2024-02-22 10:08:52= .116596877 -0800 +++ b/arch/x86/kernel/cpu/intel.c 2024-02-22 10:08:52.132597505 -0800 @@ -653,7 +653,7 @@ static void init_intel(struct cpuinfo_x8 =20 #ifdef CONFIG_X86_64 if (c->x86 =3D=3D 15) - c->x86_cache_alignment =3D c->x86_clflush_size * 2; + c->x86_cache_alignment =3D x86_clflush_size() * 2; if (c->x86 =3D=3D 6) set_cpu_cap(c, X86_FEATURE_REP_GOOD); #else diff -puN arch/x86/kernel/cpu/proc.c~x86_clflush_size-func arch/x86/kernel/= cpu/proc.c --- a/arch/x86/kernel/cpu/proc.c~x86_clflush_size-func 2024-02-22 10:08:52.= 116596877 -0800 +++ b/arch/x86/kernel/cpu/proc.c 2024-02-22 10:08:52.132597505 -0800 @@ -130,7 +130,7 @@ static int show_cpuinfo(struct seq_file if (c->x86_tlbsize > 0) seq_printf(m, "TLB size\t: %d 4K pages\n", c->x86_tlbsize); #endif - seq_printf(m, "clflush size\t: %u\n", c->x86_clflush_size); + seq_printf(m, "clflush size\t: %u\n", x86_clflush_size()); seq_printf(m, "cache_alignment\t: %d\n", c->x86_cache_alignment); seq_printf(m, "address sizes\t: %u bits physical, %u bits virtual\n", x86_phys_bits(), x86_virt_bits()); diff -puN arch/x86/lib/usercopy_64.c~x86_clflush_size-func arch/x86/lib/use= rcopy_64.c --- a/arch/x86/lib/usercopy_64.c~x86_clflush_size-func 2024-02-22 10:08:52.= 120597034 -0800 +++ b/arch/x86/lib/usercopy_64.c 2024-02-22 10:08:52.132597505 -0800 @@ -27,13 +27,12 @@ */ static void clean_cache_range(void *addr, size_t size) { - u16 x86_clflush_size =3D boot_cpu_data.x86_clflush_size; - unsigned long clflush_mask =3D x86_clflush_size - 1; + unsigned long clflush_mask =3D x86_clflush_size() - 1; void *vend =3D addr + size; void *p; =20 for (p =3D (void *)((unsigned long)addr & ~clflush_mask); - p < vend; p +=3D x86_clflush_size) + p < vend; p +=3D x86_clflush_size()) clwb(p); } =20 @@ -65,7 +64,7 @@ long __copy_user_flushcache(void *dst, c clean_cache_range(dst, size); } else { if (!IS_ALIGNED(dest, 8)) { - dest =3D ALIGN(dest, boot_cpu_data.x86_clflush_size); + dest =3D ALIGN(dest, x86_clflush_size()); clean_cache_range(dst, 1); } =20 diff -puN arch/x86/mm/pat/set_memory.c~x86_clflush_size-func arch/x86/mm/pa= t/set_memory.c --- a/arch/x86/mm/pat/set_memory.c~x86_clflush_size-func 2024-02-22 10:08:5= 2.120597034 -0800 +++ b/arch/x86/mm/pat/set_memory.c 2024-02-22 10:08:52.132597505 -0800 @@ -314,7 +314,7 @@ static unsigned long __cpa_addr(struct c =20 static void clflush_cache_range_opt(void *vaddr, unsigned int size) { - const unsigned long clflush_size =3D boot_cpu_data.x86_clflush_size; + const unsigned long clflush_size =3D x86_clflush_size(); void *p =3D (void *)((unsigned long)vaddr & ~(clflush_size - 1)); void *vend =3D vaddr + size; =20 diff -puN arch/x86/pci/common.c~x86_clflush_size-func arch/x86/pci/common.c --- a/arch/x86/pci/common.c~x86_clflush_size-func 2024-02-22 10:08:52.12059= 7034 -0800 +++ b/arch/x86/pci/common.c 2024-02-22 10:08:52.132597505 -0800 @@ -480,7 +480,7 @@ void pcibios_scan_root(int busnum) =20 void __init pcibios_set_cache_line_size(void) { - pci_dfl_cache_line_size =3D boot_cpu_data.x86_clflush_size >> 2; + pci_dfl_cache_line_size =3D x86_clflush_size() >> 2; printk(KERN_DEBUG "PCI: pci_cache_line_size set to %d bytes\n", pci_dfl_cache_line_size << 2); } diff -puN drivers/gpu/drm/drm_cache.c~x86_clflush_size-func drivers/gpu/drm= /drm_cache.c --- a/drivers/gpu/drm/drm_cache.c~x86_clflush_size-func 2024-02-22 10:08:52= .124597191 -0800 +++ b/drivers/gpu/drm/drm_cache.c 2024-02-22 10:08:52.132597505 -0800 @@ -52,7 +52,7 @@ drm_clflush_page(struct page *page) { uint8_t *page_virtual; unsigned int i; - const int size =3D boot_cpu_data.x86_clflush_size; + const int size =3D x86_clflush_size(); =20 if (unlikely(page =3D=3D NULL)) return; @@ -160,7 +160,7 @@ drm_clflush_virt_range(void *addr, unsig { #if defined(CONFIG_X86) if (static_cpu_has(X86_FEATURE_CLFLUSH)) { - const int size =3D boot_cpu_data.x86_clflush_size; + const int size =3D x86_clflush_size(); void *end =3D addr + length; =20 addr =3D (void *)(((unsigned long)addr) & -size); diff -puN drivers/gpu/drm/i915/i915_cmd_parser.c~x86_clflush_size-func driv= ers/gpu/drm/i915/i915_cmd_parser.c --- a/drivers/gpu/drm/i915/i915_cmd_parser.c~x86_clflush_size-func 2024-02-= 22 10:08:52.124597191 -0800 +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c 2024-02-22 10:08:52.132597505 = -0800 @@ -1203,8 +1203,7 @@ static u32 *copy_batch(struct drm_i915_g */ remain =3D length; if (dst_needs_clflush & CLFLUSH_BEFORE) - remain =3D round_up(remain, - boot_cpu_data.x86_clflush_size); + remain =3D round_up(remain, x86_clflush_size()); =20 ptr =3D dst; x =3D offset_in_page(offset); diff -puN drivers/gpu/drm/i915/i915_gem.c~x86_clflush_size-func drivers/gpu= /drm/i915/i915_gem.c --- a/drivers/gpu/drm/i915/i915_gem.c~x86_clflush_size-func 2024-02-22 10:0= 8:52.124597191 -0800 +++ b/drivers/gpu/drm/i915/i915_gem.c 2024-02-22 10:08:52.132597505 -0800 @@ -696,7 +696,7 @@ i915_gem_shmem_pwrite(struct drm_i915_ge */ partial_cacheline_write =3D 0; if (needs_clflush & CLFLUSH_BEFORE) - partial_cacheline_write =3D boot_cpu_data.x86_clflush_size - 1; + partial_cacheline_write =3D x86_clflush_size() - 1; =20 user_data =3D u64_to_user_ptr(args->data_ptr); remain =3D args->size; diff -puN drivers/md/dm-writecache.c~x86_clflush_size-func drivers/md/dm-wr= itecache.c --- a/drivers/md/dm-writecache.c~x86_clflush_size-func 2024-02-22 10:08:52.= 128597348 -0800 +++ b/drivers/md/dm-writecache.c 2024-02-22 10:08:52.132597505 -0800 @@ -1229,7 +1229,7 @@ static void memcpy_flushcache_optimized( */ #ifdef CONFIG_X86 if (static_cpu_has(X86_FEATURE_CLFLUSHOPT) && - likely(boot_cpu_data.x86_clflush_size =3D=3D 64) && + likely(x86_clflush_size() =3D=3D 64) && likely(size >=3D 768)) { do { memcpy((void *)dest, (void *)source, 64); _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 0C8D571742 for ; Thu, 22 Feb 2024 18:39:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627180; cv=none; b=a0ZHfg7l9yosAEn/sQ+YqDMg1Q5ZFJOVwDyW31bS/FwFseoiQ7dctCW0miIkSSIVDumT+EoINHeGUdpPQrXWFaCwyjvzn9qfz5PAPcjO8hx/ejkb7xjPKimhjJCY6pStBhfzA1s/FaImuw6pejAMetz4FbLG41DB2kzgIDlAsgU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627180; c=relaxed/simple; bh=LjZ3XkjG0M1tVloJWQZTp9CLqyaMld5LilwFQntGdmY=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=TAGh8khGUqAdkSDjfVvQg8u6UlSuDLXszCMs0UGYGbAvT+icWPohvNiVP96XyWUXqFmIy/yw8ReozMx4hHcckc6QuOxiQdWJISmjgnWGRq9t4QDkVqx8xkWsT6gUWc15Tr6Y49GCWLJsJQr0zCs00V9nHYEizD1GM7W0t9+F5cQ= 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=T6TUSdZ1; arc=none smtp.client-ip=198.175.65.16 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="T6TUSdZ1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627180; x=1740163180; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=LjZ3XkjG0M1tVloJWQZTp9CLqyaMld5LilwFQntGdmY=; b=T6TUSdZ1wxGN7ot4dagJvl6U5WnF4EB2IOsI0Y+dCQk0uCxECB/lleXi eVjsNxuK44KaP1iNbHqIGrwjGZQA/B55sh/GWydY1fkyTMZgbsLHX/CZk hWiOcOT/o/1JhvQC7j2yuFznOSKaiRzQGSm5OqCmvcRqc4GSjBnxLrb0d aJ5tnRT//D4KPSv7eVz1GdwxtYBkE1WSs6ZVq0/x39oV4w7v/nUl7FTv8 U3Kr54EdI4vTI4f9Wzx6s5oDlIGfetLc/brZbcBgLfiKvLowGE4UNAonF uBNC/qPNgdlCwx19v9Knsv7oLDXo9iZGF3SSi0hki8wlZ2JVUTBrdxqvy Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031750" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031750" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975461" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:39 -0800 Subject: [RFC][PATCH 09/34] x86/cpu: Introduce address configuration structure To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:38 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183938.662DD27C@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 Right now, 'boot_cpu_data' is established in a very ad hoc way. Random bits of the initialization code write random things to it, either blowing away state or tweaking it as they see fit. It's madness. Add some more structure to the process. Introduce an "address configuration" structure just for the boot CPU. This will be used to establish system-wide address space configuration. It is written while bringing up the boot CPU and then read *ONCE* to establish the configuration. Also introduce the first field: phys_addr_reduction_bits. This field will be used by memory encryption hardware that reduces the actual usable address bits beneath what the hardware enumerates. Signed-off-by: Dave Hansen --- b/arch/x86/include/asm/processor.h | 14 ++++++++++++++ b/arch/x86/kernel/cpu/common.c | 3 +++ b/arch/x86/kernel/setup.c | 2 ++ 3 files changed, 19 insertions(+) diff -puN arch/x86/include/asm/processor.h~bsp-addr-info arch/x86/include/a= sm/processor.h --- a/arch/x86/include/asm/processor.h~bsp-addr-info 2024-02-22 10:08:52.82= 4624673 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:08:52.828624830 -0800 @@ -163,6 +163,19 @@ struct cpuinfo_x86 { unsigned initialized : 1; } __randomize_layout; =20 +/* + * Must be written by the time ->c_bsp_init() completes. + * Consumed in get_cpu_address_sizes(). + */ +struct x86_addr_config { + /* + * How many bits of the expected or enumerated physical + * address space are unavailable? Typically set on + * platforms that use memory encryption. + */ + u8 phys_addr_reduction_bits; +}; + #define X86_VENDOR_INTEL 0 #define X86_VENDOR_CYRIX 1 #define X86_VENDOR_AMD 2 @@ -182,6 +195,7 @@ struct cpuinfo_x86 { */ extern struct cpuinfo_x86 boot_cpu_data; extern struct cpuinfo_x86 new_cpu_data; +extern struct x86_addr_config bsp_addr_config; =20 extern __u32 cpu_caps_cleared[NCAPINTS + NBUGINTS]; extern __u32 cpu_caps_set[NCAPINTS + NBUGINTS]; diff -puN arch/x86/kernel/cpu/common.c~bsp-addr-info arch/x86/kernel/cpu/co= mmon.c --- a/arch/x86/kernel/cpu/common.c~bsp-addr-info 2024-02-22 10:08:52.824624= 673 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:08:52.828624830 -0800 @@ -1125,6 +1125,9 @@ void get_cpu_address_sizes(struct cpuinf } c->x86_cache_bits =3D c->x86_phys_bits; c->x86_cache_alignment =3D x86_clflush_size(); + + /* Do this last to avoid affecting ->x86_cache_bits. */ + c->x86_phys_bits -=3D bsp_addr_config.phys_addr_reduction_bits; } =20 static void identify_cpu_without_cpuid(struct cpuinfo_x86 *c) diff -puN arch/x86/kernel/setup.c~bsp-addr-info arch/x86/kernel/setup.c --- a/arch/x86/kernel/setup.c~bsp-addr-info 2024-02-22 10:08:52.824624673 -= 0800 +++ b/arch/x86/kernel/setup.c 2024-02-22 10:08:52.828624830 -0800 @@ -131,6 +131,8 @@ struct ist_info ist_info; struct cpuinfo_x86 boot_cpu_data __read_mostly; EXPORT_SYMBOL(boot_cpu_data); =20 +struct x86_addr_config bsp_addr_config; + #if !defined(CONFIG_X86_PAE) || defined(CONFIG_X86_64) __visible unsigned long mmu_cr4_features __ro_after_init; #else _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 7F66373F00 for ; Thu, 22 Feb 2024 18:39:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627182; cv=none; b=Hn7MzfpHvTmPpWOdcabnRACtTpoXMWAtYhdIn1h+WmKGGRJyVeMozIGLDuyvQEXyZSnz6ozg7P7fSn7iU+xjzB2t7wI65bNMt5u/x8mXa+YHi1cXLW+SdTfZPdUd9sI/LVzlf8DPgGAx03HizRail7cmHgpcwktnNajs3TF7pSk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627182; c=relaxed/simple; bh=QA4nL+IB5LTiCN1WiRhJJReXahalUQ3SRSOkHWOGUt8=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=Dcp1cUC5P4IARULEctqMd1bJVXFug561eo/5XuFBjw3eRgiaHdxEqql785mym/fZq4DQTVfSUZKwNoZmtteM9sh4mNLFZEEsK3lI0NZQWKRvJAVigGHEim+KRMhItepwHUqyHosY9j2AJwZkG59zAplJ0Ty3q3F/U+ScOwXGY74= 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=TK4MxH1A; arc=none smtp.client-ip=198.175.65.16 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="TK4MxH1A" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627181; x=1740163181; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=QA4nL+IB5LTiCN1WiRhJJReXahalUQ3SRSOkHWOGUt8=; b=TK4MxH1ACISlPqEmR1W6iiTwv/3nrkrtpcK3fiNCXXm/khZ3+SXn2Egz FdUl4jhieZv1V7FiyjSgUjxu7Xz0bWp//AlhZTeH0tnVhV/pLoPCpZlVo 5IS3XMzPR2VfyCQ9qalSMlxFmQNDz7q5T6G8Xq0MGY11K1qvjOqONzzIy NciDktEfrGVQeWHSrVbAAdBPveG/uxMQ+tQT+SE58wCVqNuAN11FNiOcI ikklbMILa6+DFrefswLiRO6S2Kq4xxRSI/nC+IVdPQKvHprL/A5Cl20J9 IJdvi0+VhlH+Aopo9gOnbrCrv1RX0vaBAx6ZLgeto2jPr/eRFdicMKy6m g==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031759" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031759" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975474" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:41 -0800 Subject: [RFC][PATCH 10/34] x86/cpu/amd: Use new "address configuration" infrastructure To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:40 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183940.4F44A1FF@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 AMD memory encryption code is currently one of the 'boot_cpu_data' field twiddlers. This has led to all kinds of interesting ordering bugs at boot. Move it away from random fiddling and over to 'bsp_addr_config'. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/cpu/amd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN arch/x86/kernel/cpu/amd.c~amd-phys_addr_reduction_bits arch/x86/k= ernel/cpu/amd.c --- a/arch/x86/kernel/cpu/amd.c~amd-phys_addr_reduction_bits 2024-02-22 10:= 08:53.340644930 -0800 +++ b/arch/x86/kernel/cpu/amd.c 2024-02-22 10:08:53.344645087 -0800 @@ -622,7 +622,8 @@ static void early_detect_mem_encrypt(str * will be a value above 32-bits this is still done for * CONFIG_X86_32 so that accurate values are reported. */ - c->x86_phys_bits -=3D (cpuid_ebx(0x8000001f) >> 6) & 0x3f; + bsp_addr_config.phys_addr_reduction_bits =3D + (cpuid_ebx(0x8000001f) >> 6) & 0x3f; =20 if (IS_ENABLED(CONFIG_X86_32)) goto clear_all; _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 E1BB573F1D for ; Thu, 22 Feb 2024 18:39:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627183; cv=none; b=rn2PcW9aPL5qF8sxyGVMTKaqYYUVNm8/GOyXmeAF/GXPDUwzDTtMfRWES5arqP6FHC175LsH0FxNtmUGDBKS3/Z8DMlQJmRtlGk1T4FktBgXfnj7VLXre0AyQ8gpOSxSfFp+iIQcQmlTsnrgh8kdKmJ378Ezh+Tol7xfpgyF78U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627183; c=relaxed/simple; bh=h76VDu0EROS/tTcoE66OS4rO/lFWal4QuWjQ1nU8EXg=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=n00zM+Ke8KAd2W/djeOR7hpf2bmi6JsnjRf9UK9iRdFcTDwjAyreQ6GnsZyqguE+JFQWZYPd27dsPTSroPEhlSJ9upxL12c/wqaS0CYkU01xMyp+Inuio81EXuSKpF6XNJXT2kNCc7HNfXyFfaq2LN0NC42RLvbSemKduVV4rho= 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=BqgdZSss; arc=none smtp.client-ip=198.175.65.16 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="BqgdZSss" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627182; x=1740163182; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=h76VDu0EROS/tTcoE66OS4rO/lFWal4QuWjQ1nU8EXg=; b=BqgdZSssjo8NRgp7GKU4Z5tsL2FqiXpsrb9DYzPJeVWdQwirNSOfnJrP vKHwPP1MMNd4kXbeOTPJiG5LODCPiBo7GafhDqQZqWdZf3yaYAW/yKNXM rKhRRbbmIw5OQv6Sxzs6I8LQ7twzHmkcHZBHOy0mj3yMB8moS06khJufg 2/yFzE87FntB8zr7EAoifwyQysDFxN73ESVTD6ZMVachcZBBX8m996ynu cCI97TtK59GN+4swqkldRIPD2gIJjHbeVmUVfxcV06gx8COSP3gRDc0Ge J9oEvNyMxBmZ7f9aGYve+xord5WKaq6FQRphK95b5ouuYrpB4W4S3sDmX A==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031768" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031768" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975484" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:42 -0800 Subject: [RFC][PATCH 11/34] x86/cpu/intel: Prepare MKTME for "address configuration" infrastructure To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:41 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183941.7CB634A5@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 Intel also does memory encryption and also fiddles with the physical address bits. This is currently called for *each* CPU, but practically only done on the boot CPU because of 'mktme_status'. Move it from the "each CPU" ->c_init() function to ->c_bsp_init() where the whole thing only gets called once ever. This also necessitates moving detect_tme() and its entourage around in the file. Signed-off-by: Dave Hansen Reviewed-by: Kai Huang --- b/arch/x86/kernel/cpu/intel.c | 174 +++++++++++++++++++++----------------= ----- 1 file changed, 87 insertions(+), 87 deletions(-) diff -puN arch/x86/kernel/cpu/intel.c~intel-move-TME-detection arch/x86/ker= nel/cpu/intel.c --- a/arch/x86/kernel/cpu/intel.c~intel-move-TME-detection 2024-02-22 10:08= :53.820663775 -0800 +++ b/arch/x86/kernel/cpu/intel.c 2024-02-22 10:08:53.824663932 -0800 @@ -324,9 +324,96 @@ static void early_init_intel(struct cpui detect_ht_early(c); } =20 +#define MSR_IA32_TME_ACTIVATE 0x982 + +/* Helpers to access TME_ACTIVATE MSR */ +#define TME_ACTIVATE_LOCKED(x) (x & 0x1) +#define TME_ACTIVATE_ENABLED(x) (x & 0x2) + +#define TME_ACTIVATE_POLICY(x) ((x >> 4) & 0xf) /* Bits 7:4 */ +#define TME_ACTIVATE_POLICY_AES_XTS_128 0 + +#define TME_ACTIVATE_KEYID_BITS(x) ((x >> 32) & 0xf) /* Bits 35:32 */ + +#define TME_ACTIVATE_CRYPTO_ALGS(x) ((x >> 48) & 0xffff) /* Bits 63:48 */ +#define TME_ACTIVATE_CRYPTO_AES_XTS_128 1 + +/* Values for mktme_status (SW only construct) */ +#define MKTME_ENABLED 0 +#define MKTME_DISABLED 1 +#define MKTME_UNINITIALIZED 2 +static int mktme_status =3D MKTME_UNINITIALIZED; + +static void detect_tme(struct cpuinfo_x86 *c) +{ + u64 tme_activate, tme_policy, tme_crypto_algs; + int keyid_bits =3D 0, nr_keyids =3D 0; + static u64 tme_activate_cpu0 =3D 0; + + rdmsrl(MSR_IA32_TME_ACTIVATE, tme_activate); + + if (mktme_status !=3D MKTME_UNINITIALIZED) { + if (tme_activate !=3D tme_activate_cpu0) { + /* Broken BIOS? */ + pr_err_once("x86/tme: configuration is inconsistent between CPUs\n"); + pr_err_once("x86/tme: MKTME is not usable\n"); + mktme_status =3D MKTME_DISABLED; + + /* Proceed. We may need to exclude bits from x86_phys_bits. */ + } + } else { + tme_activate_cpu0 =3D tme_activate; + } + + if (!TME_ACTIVATE_LOCKED(tme_activate) || !TME_ACTIVATE_ENABLED(tme_activ= ate)) { + pr_info_once("x86/tme: not enabled by BIOS\n"); + mktme_status =3D MKTME_DISABLED; + return; + } + + if (mktme_status !=3D MKTME_UNINITIALIZED) + goto detect_keyid_bits; + + pr_info("x86/tme: enabled by BIOS\n"); + + tme_policy =3D TME_ACTIVATE_POLICY(tme_activate); + if (tme_policy !=3D TME_ACTIVATE_POLICY_AES_XTS_128) + pr_warn("x86/tme: Unknown policy is active: %#llx\n", tme_policy); + + tme_crypto_algs =3D TME_ACTIVATE_CRYPTO_ALGS(tme_activate); + if (!(tme_crypto_algs & TME_ACTIVATE_CRYPTO_AES_XTS_128)) { + pr_err("x86/mktme: No known encryption algorithm is supported: %#llx\n", + tme_crypto_algs); + mktme_status =3D MKTME_DISABLED; + } +detect_keyid_bits: + keyid_bits =3D TME_ACTIVATE_KEYID_BITS(tme_activate); + nr_keyids =3D (1UL << keyid_bits) - 1; + if (nr_keyids) { + pr_info_once("x86/mktme: enabled by BIOS\n"); + pr_info_once("x86/mktme: %d KeyIDs available\n", nr_keyids); + } else { + pr_info_once("x86/mktme: disabled by BIOS\n"); + } + + if (mktme_status =3D=3D MKTME_UNINITIALIZED) { + /* MKTME is usable */ + mktme_status =3D MKTME_ENABLED; + } + + /* + * KeyID bits effectively lower the number of physical address + * bits. Update cpuinfo_x86::x86_phys_bits accordingly. + */ + c->x86_phys_bits -=3D keyid_bits; +} + static void bsp_init_intel(struct cpuinfo_x86 *c) { resctrl_cpu_detect(c); + + if (cpu_has(c, X86_FEATURE_TME)) + detect_tme(c); } =20 #ifdef CONFIG_X86_32 @@ -482,90 +569,6 @@ static void srat_detect_node(struct cpui #endif } =20 -#define MSR_IA32_TME_ACTIVATE 0x982 - -/* Helpers to access TME_ACTIVATE MSR */ -#define TME_ACTIVATE_LOCKED(x) (x & 0x1) -#define TME_ACTIVATE_ENABLED(x) (x & 0x2) - -#define TME_ACTIVATE_POLICY(x) ((x >> 4) & 0xf) /* Bits 7:4 */ -#define TME_ACTIVATE_POLICY_AES_XTS_128 0 - -#define TME_ACTIVATE_KEYID_BITS(x) ((x >> 32) & 0xf) /* Bits 35:32 */ - -#define TME_ACTIVATE_CRYPTO_ALGS(x) ((x >> 48) & 0xffff) /* Bits 63:48 */ -#define TME_ACTIVATE_CRYPTO_AES_XTS_128 1 - -/* Values for mktme_status (SW only construct) */ -#define MKTME_ENABLED 0 -#define MKTME_DISABLED 1 -#define MKTME_UNINITIALIZED 2 -static int mktme_status =3D MKTME_UNINITIALIZED; - -static void detect_tme(struct cpuinfo_x86 *c) -{ - u64 tme_activate, tme_policy, tme_crypto_algs; - int keyid_bits =3D 0, nr_keyids =3D 0; - static u64 tme_activate_cpu0 =3D 0; - - rdmsrl(MSR_IA32_TME_ACTIVATE, tme_activate); - - if (mktme_status !=3D MKTME_UNINITIALIZED) { - if (tme_activate !=3D tme_activate_cpu0) { - /* Broken BIOS? */ - pr_err_once("x86/tme: configuration is inconsistent between CPUs\n"); - pr_err_once("x86/tme: MKTME is not usable\n"); - mktme_status =3D MKTME_DISABLED; - - /* Proceed. We may need to exclude bits from x86_phys_bits. */ - } - } else { - tme_activate_cpu0 =3D tme_activate; - } - - if (!TME_ACTIVATE_LOCKED(tme_activate) || !TME_ACTIVATE_ENABLED(tme_activ= ate)) { - pr_info_once("x86/tme: not enabled by BIOS\n"); - mktme_status =3D MKTME_DISABLED; - return; - } - - if (mktme_status !=3D MKTME_UNINITIALIZED) - goto detect_keyid_bits; - - pr_info("x86/tme: enabled by BIOS\n"); - - tme_policy =3D TME_ACTIVATE_POLICY(tme_activate); - if (tme_policy !=3D TME_ACTIVATE_POLICY_AES_XTS_128) - pr_warn("x86/tme: Unknown policy is active: %#llx\n", tme_policy); - - tme_crypto_algs =3D TME_ACTIVATE_CRYPTO_ALGS(tme_activate); - if (!(tme_crypto_algs & TME_ACTIVATE_CRYPTO_AES_XTS_128)) { - pr_err("x86/mktme: No known encryption algorithm is supported: %#llx\n", - tme_crypto_algs); - mktme_status =3D MKTME_DISABLED; - } -detect_keyid_bits: - keyid_bits =3D TME_ACTIVATE_KEYID_BITS(tme_activate); - nr_keyids =3D (1UL << keyid_bits) - 1; - if (nr_keyids) { - pr_info_once("x86/mktme: enabled by BIOS\n"); - pr_info_once("x86/mktme: %d KeyIDs available\n", nr_keyids); - } else { - pr_info_once("x86/mktme: disabled by BIOS\n"); - } - - if (mktme_status =3D=3D MKTME_UNINITIALIZED) { - /* MKTME is usable */ - mktme_status =3D MKTME_ENABLED; - } - - /* - * KeyID bits effectively lower the number of physical address - * bits. Update cpuinfo_x86::x86_phys_bits accordingly. - */ - c->x86_phys_bits -=3D keyid_bits; -} - static void init_cpuid_fault(struct cpuinfo_x86 *c) { u64 msr; @@ -702,9 +705,6 @@ static void init_intel(struct cpuinfo_x8 =20 init_ia32_feat_ctl(c); =20 - if (cpu_has(c, X86_FEATURE_TME)) - detect_tme(c); - init_intel_misc_features(c); =20 split_lock_init(); _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 3794A73F3C for ; Thu, 22 Feb 2024 18:39:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627185; cv=none; b=lnQ3ZPBnYR2RpXLBNATqzD+4pNxObM2soATyInsBCyojF8YloI4l+K0SeFBgK8rReqJdEHf8wkFqITwsV0rXNSj1+kihnc3WXCBSFJl9+VN5GhugQSSY5Z3KhmQeilovy0l/46GpoDL6Bo0/xjrU7pkSXv1WW8wtxrsdZzpvBGU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627185; c=relaxed/simple; bh=NH8Lr4ZEp+LyLCUOWjofEDWwYXC0tbCz8QJ2z7udv3U=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=tcMTAyF8soO31/ZJpyO6pNQRxLz8LOXACn04cb3BNLqZ52eXPiB1xN1zD5YCZqZHVMeiUf03l4sYAgI8khHn+DLTKMUaYvJ+BN16NmsT3p7LmxVpoao9YpJYMAhRupOa/M5LWbblVllL7CLVeMBtVc4kOSJjNHbcFO9TdVDRV40= 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=HAqOVzGt; arc=none smtp.client-ip=198.175.65.16 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="HAqOVzGt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627184; x=1740163184; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=NH8Lr4ZEp+LyLCUOWjofEDWwYXC0tbCz8QJ2z7udv3U=; b=HAqOVzGt0q7bY+FM0ixHEfzeUWWvDh075m1sFdIf+Ay4ZOgRIaQJQqez 6SY/fovWJToKhYYeAlmOe6fWiQyajQoXw2zox0e4c+L5IptgYcKvqlzEZ 3kNRSSznld9cznk9MryrTIPNFcgkajDoV4svxBhZUzyBMm9EZ74LyYP0G x2Xv2WuyN7XFHFAybviadUS1oNZMaE18SlJbZjcTIeY8JLQsKpK4h+AY6 HNJLoYnuOO7pFIKPUZEOlzMzXtzntTx5goEc2x1Ueh/e9Y34G0f3+rhDk gWhLOYSroPrTj02O/UwY+aAA0w+ZykL6nPrsJC0BkRnnK7Z7uN895/HB3 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031777" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031777" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975494" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:43 -0800 Subject: [RFC][PATCH 12/34] x86/cpu/intel: Actually use "address configuration" infrastructure for MKTME To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:42 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183942.601EE2E5@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 Now that the TME detection is only called once at boot, stop twiddling 'boot_cpu_data' directly and move over to 'bsp_addr_config'. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/cpu/intel.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff -puN arch/x86/kernel/cpu/intel.c~intel-addr-reduce arch/x86/kernel/cpu= /intel.c --- a/arch/x86/kernel/cpu/intel.c~intel-addr-reduce 2024-02-22 10:08:54.296= 682462 -0800 +++ b/arch/x86/kernel/cpu/intel.c 2024-02-22 10:08:54.296682462 -0800 @@ -401,11 +401,8 @@ detect_keyid_bits: mktme_status =3D MKTME_ENABLED; } =20 - /* - * KeyID bits effectively lower the number of physical address - * bits. Update cpuinfo_x86::x86_phys_bits accordingly. - */ - c->x86_phys_bits -=3D keyid_bits; + /* KeyID bits effectively lower the number of physical address bits */ + bsp_addr_config.phys_addr_reduction_bits =3D keyid_bits; } =20 static void bsp_init_intel(struct cpuinfo_x86 *c) _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 8896873F23 for ; Thu, 22 Feb 2024 18:39:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627185; cv=none; b=mXoiSdKjYM8BZHy53WUY8QS0VRRNsbR/gi7HABPwjeDB8hWyEx3BvqLo4Zs2PKyYHFrPeYe5/++rC1+B562dIyWZSIhZXpBFPb6MC9IMCg/bu57ieS4AT5++RUSgFKmtzO9QcoU9uFRpywrEHj983elrvkrI1weoVjrQw/mVgd8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627185; c=relaxed/simple; bh=/PqHI8dXtTkUo2JUzmH+1ZxYuceTKX87drzFBQmtdRg=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=qy7j+FmrhqDKWt8AXLyiqZ7eQp6fDIsvC9Tv7DpobfkmXMbKXcTwPX1njkX+k+MPIaDShksOI4mo1/sMz9PrPoKr67h/vxOtCZWYVrJeRheLBOQb71ixGNx050Vzxa8oHJcDqap6EAjj/uJsc5iWtwK816LIJp7Jy0fFa5W2RCw= 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=RX4MhTwE; arc=none smtp.client-ip=198.175.65.16 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="RX4MhTwE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627185; x=1740163185; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=/PqHI8dXtTkUo2JUzmH+1ZxYuceTKX87drzFBQmtdRg=; b=RX4MhTwEszzjfcWGhP0wbKNEql+fZcLSI8F7KVpDq9THLyRksNIvumFo Zw9QCcvOs+FzXLeM75D3PeEjdqdZrbG3DVpL1fpIm44QD63QLpDoZpa7i QJWKNUVNbRl908lyVo+7fj0OuWpUXbvmm1ePMHpjCcccu3+449ISXQ+xw BKWIuxKK9FR3IpsyhN7q8FObLN3kY2URJiDyFVQFbg5ppPMSAdMZTb9zl qUkjmOgkAIotLh+Htj8O5yu15+5wHPXMaJYwAZ0EF7GoTVOrxT9NVHskw 5iGFbLY0c0DqJxf3k/61DKiUpwkHJO3KNJeGPmOWLACR/kXFsC9obJw7o g==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031784" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031784" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975499" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:45 -0800 Subject: [RFC][PATCH 13/34] x86/boot: Use address reduction config to handle erratum To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:44 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183944.5B4F16F1@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 Continue to chip away at sites that muck with ->x86_phys_bits. This one is an oldie but a goodie: af9c142de94e ("[PATCH] x86_64: Force correct address space size for MTRR o= n some 64bit Intel Xeons") Evidently, the CPUs in question "report 40bit, but only have 36bits of physical address space." Since there's now a handy way to reduce the amount of physical address bits, use that to reduce from 40->36. This means there are now two (Intel) users of the address bits reduction feature. There is no way a 2005-era CPU will ever have TME, but it is still nice to be more explicit about the possibility of a collision. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/cpu/intel.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff -puN arch/x86/kernel/cpu/intel.c~intel-phys-addr-errata arch/x86/kerne= l/cpu/intel.c --- a/arch/x86/kernel/cpu/intel.c~intel-phys-addr-errata 2024-02-22 10:08:5= 4.772701150 -0800 +++ b/arch/x86/kernel/cpu/intel.c 2024-02-22 10:08:54.776701306 -0800 @@ -242,11 +242,6 @@ static void early_init_intel(struct cpui c->x86_cache_alignment =3D 128; #endif =20 - /* CPUID workaround for 0F33/0F34 CPU */ - if (c->x86 =3D=3D 0xF && c->x86_model =3D=3D 0x3 - && (c->x86_stepping =3D=3D 0x3 || c->x86_stepping =3D=3D 0x4)) - c->x86_phys_bits =3D 36; - /* * c->x86_power is 8000_0007 edx. Bit 8 is TSC runs at constant rate * with P/T states and does not stop in deep C-states. @@ -344,7 +339,7 @@ static void early_init_intel(struct cpui #define MKTME_UNINITIALIZED 2 static int mktme_status =3D MKTME_UNINITIALIZED; =20 -static void detect_tme(struct cpuinfo_x86 *c) +static int detect_tme(struct cpuinfo_x86 *c) { u64 tme_activate, tme_policy, tme_crypto_algs; int keyid_bits =3D 0, nr_keyids =3D 0; @@ -368,7 +363,7 @@ static void detect_tme(struct cpuinfo_x8 if (!TME_ACTIVATE_LOCKED(tme_activate) || !TME_ACTIVATE_ENABLED(tme_activ= ate)) { pr_info_once("x86/tme: not enabled by BIOS\n"); mktme_status =3D MKTME_DISABLED; - return; + return 0; } =20 if (mktme_status !=3D MKTME_UNINITIALIZED) @@ -401,16 +396,28 @@ detect_keyid_bits: mktme_status =3D MKTME_ENABLED; } =20 - /* KeyID bits effectively lower the number of physical address bits */ - bsp_addr_config.phys_addr_reduction_bits =3D keyid_bits; + return keyid_bits; } =20 static void bsp_init_intel(struct cpuinfo_x86 *c) { + int keyid_bits =3D 0; + resctrl_cpu_detect(c); =20 if (cpu_has(c, X86_FEATURE_TME)) - detect_tme(c); + keyid_bits =3D detect_tme(c); + + /* KeyID bits effectively lower the number of physical address bits */ + bsp_addr_config.phys_addr_reduction_bits =3D keyid_bits; + + /* CPUID workaround for 0F33/0F34 CPU */ + if (c->x86 =3D=3D 0xF && c->x86_model =3D=3D 0x3 + && (c->x86_stepping =3D=3D 0x3 || c->x86_stepping =3D=3D 0x4)) { + /* Warn if MKTME and this workaround collide: */ + WARN_ON_ONCE(keyid_bits); + bsp_addr_config.phys_addr_reduction_bits =3D 4; + } } =20 #ifdef CONFIG_X86_32 _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 BC6D112D20E for ; Thu, 22 Feb 2024 18:39:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627187; cv=none; b=U3WJf2Q69u1ObdDMxB8LfbJAacf6kDSK9HjviHpncmdGz6TM/O+8yREYHCrWkISKO9ZVFN3x/bfv+8/YdwWLSq/csH8NQy7xsI2TrpHBqS73yiQMSU+VC1+pwpJH75SVVhsJyDs0Nukf/rvU9Qc0inacM86gHT2W/ZNhFb9icc4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627187; c=relaxed/simple; bh=MxDsNdC/Re/7k1BR0zpTGqTAJuSw/SegugBpbmZ6QI8=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=K3UiVI9/ZGf9Gy4apX77bpfJuXmWWX9/Ffp2hh9wG6iH/14jeag+6AshZAsXcRe5KJ4kPh1PMT+9lbckSmenNBZjIfr/2QN628YorhrpyicQRcpoInu9mNoIEEIOxtQ+HO0A3bmMxp6ww9Z6FBnnxqNKkTz9tUNZ/udILWJlrK8= 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=FcaNhyrb; arc=none smtp.client-ip=198.175.65.16 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="FcaNhyrb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627186; x=1740163186; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=MxDsNdC/Re/7k1BR0zpTGqTAJuSw/SegugBpbmZ6QI8=; b=FcaNhyrblZD/yxmmP1MJ/1bCBooha2xJU+c0BlVlTryNcSbp5mAfYOMI sIqktRSMzmCkAj0HnTbWh8mS3XfYP9Tp5SLy1o2D62x1ydc7IMT3C0Otp yLP1Y0CD29fbCD50o70DV3PRMUXmDLitvrG5sn5SwUqLvS2J2a7nF4y6d S4Jc3l9EOh7ypH0E7UvIZc2h2pwmEFYysYRb9zDTNTQpBc22SwSiArcF0 2KhlMNtV2qvLlniEyXwTu49gYtFLWV068vBVqsLANnnUVAO8n5Zkr/Lyi gHjhHD6bbHVt4Hc9jDBDcIF4MxGXPIhKIJB/qnL8OWAVx3XU3wJPMxhk6 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031792" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031792" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975510" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:46 -0800 Subject: [RFC][PATCH 14/34] x86/cpu: Remove default physical address space settings To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:45 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183945.877FCD8C@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 At this point, the secondary CPUs' c->x86_phys_bits should be unused. The = boot CPU values were also established long before reaching here. This can only serve to sow chaos. Remove the twiddling. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/cpu/common.c | 2 -- 1 file changed, 2 deletions(-) diff -puN arch/x86/kernel/cpu/common.c~no-default-bit-setting-phys arch/x86= /kernel/cpu/common.c --- a/arch/x86/kernel/cpu/common.c~no-default-bit-setting-phys 2024-02-22 1= 0:08:55.256720151 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:08:55.260720308 -0800 @@ -1827,12 +1827,10 @@ static void identify_cpu(struct cpuinfo_ c->topo.l2c_id =3D BAD_APICID; #ifdef CONFIG_X86_64 c->x86_clflush_size =3D 64; - c->x86_phys_bits =3D 36; c->x86_virt_bits =3D 48; #else c->cpuid_level =3D -1; /* CPUID not detected */ c->x86_clflush_size =3D 32; - c->x86_phys_bits =3D 32; c->x86_virt_bits =3D 32; #endif c->x86_cache_alignment =3D x86_clflush_size(); _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 02214137911 for ; Thu, 22 Feb 2024 18:39:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627189; cv=none; b=pvMoZ0xPoXiOZpUVjXR0wzpw403puUnQOlerVpPqqWxOUzz25E6aKfqSvYNBrIq0E4EHo/OwrENpp0ivkvIAsHG5u50fPrEPKqRDJd8dxlhTN15h+W+8GYnr9xM5MItv/JWXwliJ1sgAoYhNttcX0NH9R7nshD77aneIYB26+eU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627189; c=relaxed/simple; bh=84dXCfycOCeIkvzfMQyuyX9PyM2pSN/8B8x9nVAoz80=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=JrJclWTTrqo05/ScCDvgA2d+eODfrp5XF0yl7UmwlC0Q2VOLpA4ruEAgWLZiO67sQD0kJQLkjpPk25XtQHRiYCiisbkP4GssrSWYDUpK4raRuVdM5UGgDQn099ZBw2Ceb/z5OKhTp5rbfPlwZ7qKNz1prkuOcYd7qn8jaojLmFU= 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=U++5FIQ9; arc=none smtp.client-ip=198.175.65.16 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="U++5FIQ9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627188; x=1740163188; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=84dXCfycOCeIkvzfMQyuyX9PyM2pSN/8B8x9nVAoz80=; b=U++5FIQ9pj7EBpG9tDUwXemy+cPOItPwJD86d+n3jPf3dZW8mgdbvZJu sNLaQ41H8bzPexATwOxZ8HZ9AbKrGGMbGvAug7jB7pNbFp/p/5WXHmUlm mgUZv0kcSQvdSR1WQcbr4x8MhzjzA0TP+/8U/qIuIONEz5RcR754MPLyO q1oHcAZsnv/g2Ezok1JSCundSXworTrL2MKstSmPRvE/+aU0IVzMSGjih QlW3VNxNNUCHkubHyrok8MNZfOoIQUtqCHXGQQcMg+4xKevUpoOfq38SC AqeV3nzCnjYMouKLuIdxO8Yv8fBtQ5SvoYVGD+HqGnQSJDjJpVs9/CLut g==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031804" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031804" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975520" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:47 -0800 Subject: [RFC][PATCH 15/34] x86/cpu: Remove default x86_phys_bits assignment To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:46 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183946.76C864D3@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 This was presumably needed for *some* reason at some point. It is useless now. Remove it. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/setup.c | 1 - 1 file changed, 1 deletion(-) diff -puN arch/x86/kernel/setup.c~no-early-max_phys_bits-assign arch/x86/ke= rnel/setup.c --- a/arch/x86/kernel/setup.c~no-early-max_phys_bits-assign 2024-02-22 10:0= 8:55.736738995 -0800 +++ b/arch/x86/kernel/setup.c 2024-02-22 10:08:55.740739152 -0800 @@ -752,7 +752,6 @@ void __init setup_arch(char **cmdline_p) __flush_tlb_all(); #else printk(KERN_INFO "Command line: %s\n", boot_command_line); - boot_cpu_data.x86_phys_bits =3D MAX_PHYSMEM_BITS; #endif =20 /* _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 47F886AF8E for ; Thu, 22 Feb 2024 18:39:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627190; cv=none; b=EYAZy7n3Sx5beT083NILmsSYl5QULd5yI/A4RlLVEwUVwNS1t+6tfV1iHspTlk011dQbqmSYblo9XLbKvANGxSQ1ecak92L9DvpzNM/ux4n6/w2wEqD7sfnJk9uA3f0pU2XSXugEZQLULMA/9YDMVFXsFf0jJjPrcepaYym8z6E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627190; c=relaxed/simple; bh=rjA2Z8evUUaXAhyNDxtdKE3+0AQEccNWNKV6rzUVbYE=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=aR0ITJAujxSrfmULzY2a1VqLCz/Y459fs+gZdbJamuB3oFAKCQbHlxyPK1FzC7tgoozoxqOkDGk25/aDgGKluV6nKMWvvLI6olx29PcjlgrSFFaY6RbQqqE0L5XpoSznEw3wkQsLawhLEO9KG2ZE7fLaSNTnR37OGSFIn3+VWn0= 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=YsxrWZa+; arc=none smtp.client-ip=198.175.65.16 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="YsxrWZa+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627189; x=1740163189; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=rjA2Z8evUUaXAhyNDxtdKE3+0AQEccNWNKV6rzUVbYE=; b=YsxrWZa+jEObrCg6oCL6cDtT7Zbs04GAR24RfVMWECB3aMMV9UrRfuCD SBU83y/LjtdRiP2MZvdnXjsxGQr6YsTKS5OVTQynto1jwWk5GrBeBHNr2 ZRkrKdtitYT0AYPPqu1wswzz6b6O5qMgUlXz5ghLxBulkzXZmKlF67j3V 2o1iDD872007fz+HAPkrCC9D5dAyd2/P46lAWMe6/nOMjaFV2vLTzYIYq 48MMS+wEf+3yYs0qU5SAyDR5EMMnkRpn/8uWqUKSKjhJkphgXpyKxrsZb ojl1BrmiLJrmBZPnk+TweCsPFJCWU/QsrKd7VHGG2V0b3E1k9HpC30t+i w==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031810" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031810" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975529" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:48 -0800 Subject: [RFC][PATCH 16/34] x86/cpu: Move physical address limit out of cpuinfo_x86 To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:48 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183947.32D9A553@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 no longer any direct references to cpuinfo_x86->x86_phys_bits. The only remaining references are to 'boot_cpu_data' via the x86_phys_bits() helper. This means the farce that x86_phys_bits is per-cpu data can end. Remove it from cpuinfo_x86 and add it to a new global data structure: 'x86_config'. (Better names welcome) Signed-off-by: Dave Hansen --- b/arch/x86/include/asm/processor.h | 16 ++++++++++++++-- b/arch/x86/kernel/cpu/common.c | 12 ++++++------ b/arch/x86/kernel/setup.c | 1 + 3 files changed, 21 insertions(+), 8 deletions(-) diff -puN arch/x86/include/asm/processor.h~no-cpu-data-phys_bits arch/x86/i= nclude/asm/processor.h --- a/arch/x86/include/asm/processor.h~no-cpu-data-phys_bits 2024-02-22 10:= 08:56.220757996 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:08:56.228758310 -0800 @@ -118,7 +118,6 @@ struct cpuinfo_x86 { __u32 vmx_capability[NVMXINTS]; #endif __u8 x86_virt_bits; - __u8 x86_phys_bits; /* CPUID returned core id bits: */ __u8 x86_coreid_bits; /* Max extended CPUID function supported: */ @@ -176,6 +175,19 @@ struct x86_addr_config { u8 phys_addr_reduction_bits; }; =20 +/* + * System-wide configuration that is shared by all processors. + * + * Built in early_cpu_init() on the boot CPU and and never + * modified after that. + */ +struct x86_sys_config { + /* Physical address bits supported by all processors */ + u8 phys_bits; +}; + +extern struct x86_sys_config x86_config; + #define X86_VENDOR_INTEL 0 #define X86_VENDOR_CYRIX 1 #define X86_VENDOR_AMD 2 @@ -783,7 +795,7 @@ static inline void weak_wrmsr_fence(void =20 static inline u8 x86_phys_bits(void) { - return boot_cpu_data.x86_phys_bits; + return x86_config.phys_bits; } =20 static inline u8 x86_virt_bits(void) diff -puN arch/x86/kernel/cpu/common.c~no-cpu-data-phys_bits arch/x86/kerne= l/cpu/common.c --- a/arch/x86/kernel/cpu/common.c~no-cpu-data-phys_bits 2024-02-22 10:08:5= 6.224758153 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:08:56.228758310 -0800 @@ -1107,27 +1107,27 @@ void get_cpu_address_sizes(struct cpuinf cpuid(0x80000008, &eax, &ebx, &ecx, &edx); =20 c->x86_virt_bits =3D (eax >> 8) & 0xff; - c->x86_phys_bits =3D eax & 0xff; + x86_config.phys_bits =3D eax & 0xff; } else { if (IS_ENABLED(CONFIG_X86_64)) { + x86_config.phys_bits =3D 36; c->x86_clflush_size =3D 64; - c->x86_phys_bits =3D 36; c->x86_virt_bits =3D 48; } else { + x86_config.phys_bits =3D 32; c->x86_clflush_size =3D 32; c->x86_virt_bits =3D 32; - c->x86_phys_bits =3D 32; =20 if (cpu_has(c, X86_FEATURE_PAE) || cpu_has(c, X86_FEATURE_PSE36)) - c->x86_phys_bits =3D 36; + x86_config.phys_bits =3D 36; } } - c->x86_cache_bits =3D c->x86_phys_bits; + c->x86_cache_bits =3D x86_config.phys_bits; c->x86_cache_alignment =3D x86_clflush_size(); =20 /* Do this last to avoid affecting ->x86_cache_bits. */ - c->x86_phys_bits -=3D bsp_addr_config.phys_addr_reduction_bits; + x86_config.phys_bits -=3D bsp_addr_config.phys_addr_reduction_bits; } =20 static void identify_cpu_without_cpuid(struct cpuinfo_x86 *c) diff -puN arch/x86/kernel/setup.c~no-cpu-data-phys_bits arch/x86/kernel/set= up.c --- a/arch/x86/kernel/setup.c~no-cpu-data-phys_bits 2024-02-22 10:08:56.224= 758153 -0800 +++ b/arch/x86/kernel/setup.c 2024-02-22 10:08:56.228758310 -0800 @@ -132,6 +132,7 @@ struct cpuinfo_x86 boot_cpu_data __read_ EXPORT_SYMBOL(boot_cpu_data); =20 struct x86_addr_config bsp_addr_config; +struct x86_sys_config x86_config __read_mostly; =20 #if !defined(CONFIG_X86_PAE) || defined(CONFIG_X86_64) __visible unsigned long mmu_cr4_features __ro_after_init; _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 0AC2713BADF for ; Thu, 22 Feb 2024 18:39:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627191; cv=none; b=PT6r0ncInl0uEZ7vPq5Ga4ToTSjJTGAlhV2kpiCtUqyJzfiW+62dweBwhGaXoE+3t3AOddaNjdjT67TFPb0Gf+CtSS0Z2eHKntl5wpBnNOq2OJW6kFp4TPgEqXVfA7Us94KPakrnZhoIIA28JIVozwwvDFQ1eekqbH++FIQ/TT4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627191; c=relaxed/simple; bh=buneXK45S59L265wMYbZIbp62iDWv2uaPtRPDjg659o=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=R6lOHY18iExwQP8KQ6LwygOkH4zuUR4TN69+7WE4PmP8mzsnInPYWYqLogFlQh9zaLyzi9sxUEKY35ews4XbuEhrpakv4Jm5GKJlBcDcVuM6JsRSSHUV9aft/7KDkDn+wS6MBx4hsizryCcduUiNglCgiTkDmmhphazDiFSxW7Q= 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=I9hzTZxp; arc=none smtp.client-ip=198.175.65.16 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="I9hzTZxp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627191; x=1740163191; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=buneXK45S59L265wMYbZIbp62iDWv2uaPtRPDjg659o=; b=I9hzTZxpfBReaGeCDchDKhaAiEYy/6+MJj4eyVwR918nKwR4z+gycbm6 QhxljElDmPCdq4YeMmuk8Y5v3XN2aR8nX+5y+ekKlba73wlriQRPbqW/l flY47BQy2GJKFR1WVVugmksNLtXzHhpVNuy4ZojwT7I88ShEvmRy0Pplk OzWmipRHUEMFOerhUwEtwnBry7gZii2byKfqzxIX+KEBzVZGbl3KLyI2v lMETii/FwjG4bstfRa6YHRohs6aCgJTJYPfYBRIMqxhohbel0g4K60R1u Vytsyjgwa4t3tAhuDCFlszw8G9Rzgn6a7oBso2ANUjyAm7uDEjkKN0a99 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031816" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031816" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975536" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:50 -0800 Subject: [RFC][PATCH 17/34] x86/cpu: Move virtual address limit out of cpuinfo_x86 To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:49 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183949.9E1C5A1E@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 no longer any direct references to cpuinfo_x86->x86_virt_bits. The only remaining references are to 'boot_cpu_data' via the x86_virt_bits() helper. This means the farce that x86_virt_bits is per-cpu data can end. Remove it from cpuinfo_x86 and add it to 'x86_config'. Signed-off-by: Dave Hansen --- b/arch/x86/include/asm/processor.h | 6 +++--- b/arch/x86/kernel/cpu/common.c | 8 +++----- b/arch/x86/mm/maccess.c | 9 +++++---- 3 files changed, 11 insertions(+), 12 deletions(-) diff -puN arch/x86/include/asm/processor.h~no-cpu-data-virt_bits arch/x86/i= nclude/asm/processor.h --- a/arch/x86/include/asm/processor.h~no-cpu-data-virt_bits 2024-02-22 10:= 08:56.748778725 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:08:56.752778882 -0800 @@ -117,7 +117,6 @@ struct cpuinfo_x86 { #ifdef CONFIG_X86_VMX_FEATURE_NAMES __u32 vmx_capability[NVMXINTS]; #endif - __u8 x86_virt_bits; /* CPUID returned core id bits: */ __u8 x86_coreid_bits; /* Max extended CPUID function supported: */ @@ -182,8 +181,9 @@ struct x86_addr_config { * modified after that. */ struct x86_sys_config { - /* Physical address bits supported by all processors */ + /* Address bits supported by all processors */ u8 phys_bits; + u8 virt_bits; }; =20 extern struct x86_sys_config x86_config; @@ -800,7 +800,7 @@ static inline u8 x86_phys_bits(void) =20 static inline u8 x86_virt_bits(void) { - return boot_cpu_data.x86_virt_bits; + return x86_config.virt_bits; } =20 static inline u8 x86_clflush_size(void) diff -puN arch/x86/kernel/cpu/common.c~no-cpu-data-virt_bits arch/x86/kerne= l/cpu/common.c --- a/arch/x86/kernel/cpu/common.c~no-cpu-data-virt_bits 2024-02-22 10:08:5= 6.748778725 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:08:56.752778882 -0800 @@ -1106,17 +1106,17 @@ void get_cpu_address_sizes(struct cpuinf if (vp_bits_from_cpuid) { cpuid(0x80000008, &eax, &ebx, &ecx, &edx); =20 - c->x86_virt_bits =3D (eax >> 8) & 0xff; + x86_config.virt_bits =3D (eax >> 8) & 0xff; x86_config.phys_bits =3D eax & 0xff; } else { if (IS_ENABLED(CONFIG_X86_64)) { x86_config.phys_bits =3D 36; + x86_config.virt_bits =3D 48; c->x86_clflush_size =3D 64; - c->x86_virt_bits =3D 48; } else { x86_config.phys_bits =3D 32; + x86_config.virt_bits =3D 32; c->x86_clflush_size =3D 32; - c->x86_virt_bits =3D 32; =20 if (cpu_has(c, X86_FEATURE_PAE) || cpu_has(c, X86_FEATURE_PSE36)) @@ -1827,11 +1827,9 @@ static void identify_cpu(struct cpuinfo_ c->topo.l2c_id =3D BAD_APICID; #ifdef CONFIG_X86_64 c->x86_clflush_size =3D 64; - c->x86_virt_bits =3D 48; #else c->cpuid_level =3D -1; /* CPUID not detected */ c->x86_clflush_size =3D 32; - c->x86_virt_bits =3D 32; #endif c->x86_cache_alignment =3D x86_clflush_size(); memset(&c->x86_capability, 0, sizeof(c->x86_capability)); diff -puN arch/x86/mm/maccess.c~no-cpu-data-virt_bits arch/x86/mm/maccess.c --- a/arch/x86/mm/maccess.c~no-cpu-data-virt_bits 2024-02-22 10:08:56.75277= 8882 -0800 +++ b/arch/x86/mm/maccess.c 2024-02-22 10:08:56.752778882 -0800 @@ -16,11 +16,12 @@ bool copy_from_kernel_nofault_allowed(co return false; =20 /* - * Allow everything during early boot before 'x86_virt_bits' - * is initialized. Needed for instruction decoding in early - * exception handlers. + * Allow everything during early boot before 'virt_bits' is + * initialized. Needed for instruction decoding in early + * exception handlers. Avoid the helper because it may do + * error checking for being uninitiazed. */ - if (!x86_virt_bits()) + if (!x86_config.virt_bits) return true; =20 return __is_canonical_address(vaddr, x86_virt_bits()); _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 040E7137932 for ; Thu, 22 Feb 2024 18:39:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627192; cv=none; b=DslV5nsxNgrAz7Yzu5gKuQKI1/HbU6Mib5R6C6skahxlDSob69q1ZEpg14tcLwETT2sdvx+5OEPxP7awdXqug20pN+4D+z6wDeDxdmN4Yfv5PTvVcjckV00oS+8usRepIrTwUN3xZ1gZ4F5epmcAI8fqo1tBsWm752jcuYs3+e8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627192; c=relaxed/simple; bh=tiABm/o18DPqMhSfzvK1w9HdGuxe4IVkXU92OGIYjng=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=UZOLwPqxKMatEtR2m5EWFHBH7DbBt8WPgzBcombK7wRVaZk2FCeAka8gPV7w79SbzER5ewNUjGGLvcKjNco+GKzYMdKJIlCjEwO56qEb+Rfd0ZCnE3H0KOehfs+5GJyBZDFf6WMP7XHUNbC5QOkdKvgY9qc1n5YL6iL3p0jJRMo= 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=YZHNMckL; arc=none smtp.client-ip=198.175.65.16 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="YZHNMckL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627192; x=1740163192; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=tiABm/o18DPqMhSfzvK1w9HdGuxe4IVkXU92OGIYjng=; b=YZHNMckLx4OE1Yfdx78bBnLVuhg24KVBrYgHQmss2t6vqs4Ti9CZpKKn fJA+E9ydCEasxmUcYtyoLYxx1wIMk0lmaziSRKUzpoukRn1c+nqpdPgaD fw/gtCFdUZjL4GhrEGSCn9WYncUr6G8rQAFzcg6CZLU1ZaTN6bPcDYSch sHSVGzreIjNFqSKuXT8xDyukMMG1hSB0O5QwXtTRw85p1WycT80qdqxNe pbdeyxYh5aPRd900FrFxVS83TBLchWg49t1a8jCkYt8mUtsgRLkDzDg4+ mCV7TCHqOFYGeEY2itCuqW16drs/amtK3OVj/tQarV77tcQaFk+ni7lpd g==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031824" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031824" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975552" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:51 -0800 Subject: [RFC][PATCH 18/34] x86/cpu/centaur: Move cache alignment override to BSP init To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:50 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183950.92A959F2@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 'x86_cache_alignment' is yet another system-wide value which is stored per-cpu. Stop initializing it per-cpu on (some) Centaur CPUs and move it to a new BSP init function. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/cpu/centaur.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff -puN arch/x86/kernel/cpu/centaur.c~centaur-c_early_init arch/x86/kerne= l/cpu/centaur.c --- a/arch/x86/kernel/cpu/centaur.c~centaur-c_early_init 2024-02-22 10:08:5= 7.268799139 -0800 +++ b/arch/x86/kernel/cpu/centaur.c 2024-02-22 10:08:57.268799139 -0800 @@ -61,12 +61,8 @@ static void init_c3(struct cpuinfo_x86 * if (c->x86_model >=3D 6 && c->x86_model < 9) set_cpu_cap(c, X86_FEATURE_3DNOW); #endif - if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) { - c->x86_cache_alignment =3D x86_clflush_size() * 2; - set_cpu_cap(c, X86_FEATURE_REP_GOOD); - } - - if (c->x86 >=3D 7) + if ((c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) || + (c->x86 >=3D 7)) set_cpu_cap(c, X86_FEATURE_REP_GOOD); } =20 @@ -217,6 +213,12 @@ static void init_centaur(struct cpuinfo_ init_ia32_feat_ctl(c); } =20 +static void bsp_init_centaur(struct cpuinfo_x86 *c) +{ + if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) + c->x86_cache_alignment =3D x86_clflush_size() * 2; +} + #ifdef CONFIG_X86_32 static unsigned int centaur_size_cache(struct cpuinfo_x86 *c, unsigned int size) @@ -241,6 +243,7 @@ static const struct cpu_dev centaur_cpu_ .c_vendor =3D "Centaur", .c_ident =3D { "CentaurHauls" }, .c_early_init =3D early_init_centaur, + .c_bsp_init =3D bsp_init_centaur, .c_init =3D init_centaur, #ifdef CONFIG_X86_32 .legacy_cache_size =3D centaur_size_cache, _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 A7360140372 for ; Thu, 22 Feb 2024 18:39:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627194; cv=none; b=JahPKSN0VZq3GpZCzOQODPzEt9ThSsKq7srtCh4mKh454t+Gi0UNxtT+GLJLHgSRMah2Bw8TABxoHM+Spga33KvCFtOoldDsv4N5xeXUpGwRXLwfuFITdsv+nejvo3/yVLihxw74LWMtRZspzal7qk+dBgy5Vv0udLln3tnsIk0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627194; c=relaxed/simple; bh=lVSBkQ+5G44BZu5dX85c0yqtBnGNPsKMRwhEBPumIA8=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=cp4P7gzJj52hFDGOCF854WZcyxPfGmR0bxpWHi6kzQFKiFOiCBHACIMd5hwdUilJC6HoXowXuI36Pz1JhxvxbYq8Squ01OcZyM486rF6Lif4Z6eOzRFs48fWrk+c7lircczl6qaG3bUTmlHJz2n0omP1SiXbpPa+RWIGB5XxsYc= 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=IVvH0HT5; arc=none smtp.client-ip=198.175.65.16 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="IVvH0HT5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627193; x=1740163193; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=lVSBkQ+5G44BZu5dX85c0yqtBnGNPsKMRwhEBPumIA8=; b=IVvH0HT5ijKUg7MA6/qPZlzP9TCpjvpT6AH0x7VLswbz9gGtWB8qbPrw JKjx9UYHoCPf0wc6UkSS/jiVnya/MQHw0Poyvr4HbNBzLrHoqgzM7eCDj AmyixkCd8Ye29FzblJ+v8VRAS8gSgOWcnuxo1VMQMriWYTRVvYOYxCmhh +2PmfwZtWfPg2fKU1SHDTHXJTZxWiWt+h6pz2u7crDOihVKc3JhpGh+La eq3kb9LBch2w1nBxHnaqzFAcEmPcQ2adoN3usJnzOdwtQUXxtEcTQ5Buz jkoNvtBGe0SBruu9JAsdy5j5/jJ2Z9c5MJ7b5UeJIdeHySNnYKCfVMqsE A==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031831" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031831" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975561" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:52 -0800 Subject: [RFC][PATCH 19/34] x86/cpu: Introduce cache alignment multiplier To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:51 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183951.6BCC4D89@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 currently tracks two different but similar-sounding values: x86_clflush_size and x86_cache_alignment x86_clflush_size is literally the size of the cacheline which is also the architectural granularity at which CLFLUSH operates. But some weirdo CPUs like the Pentium 4 do some operations across two cachelines. Their CLFLUSH still works at 'x86_clflush_size' but they need some operations aligned to that double cacheline to work well, thus 'x86_cache_alignment'. Introduce and use a 'bsp_addr_config' field for these systems. Note that the Intel Family 15 code actually did this in two different sites, one for 32-bit and one for 64-bit. Unify them. Signed-off-by: Dave Hansen --- b/arch/x86/include/asm/processor.h | 7 +++++++ b/arch/x86/kernel/cpu/centaur.c | 2 +- b/arch/x86/kernel/cpu/common.c | 3 +++ b/arch/x86/kernel/cpu/intel.c | 10 ++++------ 4 files changed, 15 insertions(+), 7 deletions(-) diff -puN arch/x86/include/asm/processor.h~x86_cache_alignment_mult arch/x8= 6/include/asm/processor.h --- a/arch/x86/include/asm/processor.h~x86_cache_alignment_mult 2024-02-22 = 10:08:57.732817356 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:08:57.740817669 -0800 @@ -172,6 +172,13 @@ struct x86_addr_config { * platforms that use memory encryption. */ u8 phys_addr_reduction_bits; + + /* + * "x86_clflush_size" is the size of an actual cacheline. + * Allow systems to specify a multiplier where alignment + * will take place at a more coarse granularity. + */ + u8 cache_align_mult; }; =20 /* diff -puN arch/x86/kernel/cpu/centaur.c~x86_cache_alignment_mult arch/x86/k= ernel/cpu/centaur.c --- a/arch/x86/kernel/cpu/centaur.c~x86_cache_alignment_mult 2024-02-22 10:= 08:57.732817356 -0800 +++ b/arch/x86/kernel/cpu/centaur.c 2024-02-22 10:08:57.740817669 -0800 @@ -216,7 +216,7 @@ static void init_centaur(struct cpuinfo_ static void bsp_init_centaur(struct cpuinfo_x86 *c) { if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) - c->x86_cache_alignment =3D x86_clflush_size() * 2; + bsp_addr_config.cache_align_mult =3D 2; } =20 #ifdef CONFIG_X86_32 diff -puN arch/x86/kernel/cpu/common.c~x86_cache_alignment_mult arch/x86/ke= rnel/cpu/common.c --- a/arch/x86/kernel/cpu/common.c~x86_cache_alignment_mult 2024-02-22 10:0= 8:57.736817513 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:08:57.740817669 -0800 @@ -1124,7 +1124,10 @@ void get_cpu_address_sizes(struct cpuinf } } c->x86_cache_bits =3D x86_config.phys_bits; + c->x86_cache_alignment =3D x86_clflush_size(); + if (bsp_addr_config.cache_align_mult) + c->x86_cache_alignment *=3D bsp_addr_config.cache_align_mult; =20 /* Do this last to avoid affecting ->x86_cache_bits. */ x86_config.phys_bits -=3D bsp_addr_config.phys_addr_reduction_bits; diff -puN arch/x86/kernel/cpu/intel.c~x86_cache_alignment_mult arch/x86/ker= nel/cpu/intel.c --- a/arch/x86/kernel/cpu/intel.c~x86_cache_alignment_mult 2024-02-22 10:08= :57.736817513 -0800 +++ b/arch/x86/kernel/cpu/intel.c 2024-02-22 10:08:57.740817669 -0800 @@ -236,10 +236,6 @@ static void early_init_intel(struct cpui =20 #ifdef CONFIG_X86_64 set_cpu_cap(c, X86_FEATURE_SYSENTER32); -#else - /* Netburst reports 64 bytes clflush size, but does IO in 128 bytes */ - if (c->x86 =3D=3D 15 && c->x86_cache_alignment =3D=3D 64) - c->x86_cache_alignment =3D 128; #endif =20 /* @@ -418,6 +414,10 @@ static void bsp_init_intel(struct cpuinf WARN_ON_ONCE(keyid_bits); bsp_addr_config.phys_addr_reduction_bits =3D 4; } + + /* Netburst reports 64 bytes clflush size, but does IO in 128 bytes */ + if (c->x86 =3D=3D 15) + bsp_addr_config.cache_align_mult =3D 2; } =20 #ifdef CONFIG_X86_32 @@ -659,8 +659,6 @@ static void init_intel(struct cpuinfo_x8 set_cpu_bug(c, X86_BUG_MONITOR); =20 #ifdef CONFIG_X86_64 - if (c->x86 =3D=3D 15) - c->x86_cache_alignment =3D x86_clflush_size() * 2; if (c->x86 =3D=3D 6) set_cpu_cap(c, X86_FEATURE_REP_GOOD); #else _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 767BF13BAF5 for ; Thu, 22 Feb 2024 18:39:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627194; cv=none; b=Rr8ffdtfI0MbPrOEck+X1Nn++VHE0kO3VOiWOl4VWxcfiwdzRturwtSQKuQml+CM04CCDZBUm+wAY7x/1YfaKKTT0ldEY7E0MSrFZJQw070xXz9+PlPCrTHGGO8ziyL2E1pFSjJkOROu7tY2Q8wymlgn4DjEi0c0eFByqx2AaO8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627194; c=relaxed/simple; bh=kGouo5XDP+/c1NdKS2yBopq/rLDDpdyzpRegRLzF9jA=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=vD3Ta8PUXHe6XCoHALF7KAJAKYAO5Tb/two4XnUrekuc4T+YV4EI2F2s1MBNHL2LXIfh9k6iKjJ1AUIOdHGh8s8UEQc4uYd8PuSePO8dkbz5/kY7bjhvUm7lpG0Ew8O9YNj+di8JQ9VP2cxRBt5JpZe0Gndl0viO17wgLjadIE0= 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=Y0zy/b1Y; arc=none smtp.client-ip=198.175.65.16 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="Y0zy/b1Y" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627194; x=1740163194; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=kGouo5XDP+/c1NdKS2yBopq/rLDDpdyzpRegRLzF9jA=; b=Y0zy/b1YVWFQDF7r8c/1YUotaI9XSlAUQEvIpbBObu/4/qrKGZdMvoAS UQt4YWNLAnmlsVQO8aX0RR2SgB+PfHbxv6BFcXGKr0DDWwnTy2l68Sla6 2ptN38bE38zQQQmWfC/wlpkxj/Pzp3eD35zOzDj7rbyfEYlVbiFXVGi2B bLhTr1x4vjU71STs0PeLkzsdSZ89bfW4vNcP0AP1FNMgNp8bZmj072neA zOfHUi9pxEXS8IK5c/wDGbOFn7UMwGuPm+2DbeUeSNnvd0xz1pOPL2UDn AcLIbUz9muiEoMG5M20yA7k/i8JbfOmzR6PXL97Kq7+ScV4KxfJp/Krv/ Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031838" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031838" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975574" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:53 -0800 Subject: [RFC][PATCH 20/34] x86/cpu: Remove superfluous cache alignment assignments To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:53 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183953.97E25EC4@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 Now that the boot CPU's ->x86_cache_alignment is authoritative and is is consistently established, these other copies only serve to clobber it needlessly. Remove them. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/cpu/common.c | 2 -- 1 file changed, 2 deletions(-) diff -puN arch/x86/kernel/cpu/common.c~dup-cache-alignment arch/x86/kernel/= cpu/common.c --- a/arch/x86/kernel/cpu/common.c~dup-cache-alignment 2024-02-22 10:08:58.= 260838084 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:08:58.260838084 -0800 @@ -956,7 +956,6 @@ void cpu_detect(struct cpuinfo_x86 *c) if (cap0 & (1<<19)) { if (c =3D=3D &boot_cpu_data) c->x86_clflush_size =3D ((misc >> 8) & 0xff) * 8; - c->x86_cache_alignment =3D x86_clflush_size(); } } } @@ -1834,7 +1833,6 @@ static void identify_cpu(struct cpuinfo_ c->cpuid_level =3D -1; /* CPUID not detected */ c->x86_clflush_size =3D 32; #endif - c->x86_cache_alignment =3D x86_clflush_size(); memset(&c->x86_capability, 0, sizeof(c->x86_capability)); #ifdef CONFIG_X86_VMX_FEATURE_NAMES memset(&c->vmx_capability, 0, sizeof(c->vmx_capability)); _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 B7BE614938E for ; Thu, 22 Feb 2024 18:39:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627196; cv=none; b=tjufXbFUmDQRFQzjZf2CTK+M4pWV8xFfhXDLGPgyinMSMLoguKV84s1N8FM5E8f/93FHnqgfvD1jljjJWAy/hkMti+2bTFplzhx+4pJGyaeqkPSKAQaOJXX+GNhLH1rMgS6sU9n4vqo0K06TKROJgrQc2jriqa4jDE4S8kd0vy8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627196; c=relaxed/simple; bh=nx/rpbn5tIj5Y+XhodSjBqWfpjIWIvV6is8OneYevSs=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=Uu1QYc3UnCBO3ZOFRNsMTYDc1IzZ3ktQwkAQssJLX8GVl2JrrKP2B7a/mZyqsSKV+s1Nv0iD2HMcKpMnkpZMjIJRA6E5GnGnHuzuSQtqXABbUbMMJaMaIOHoLYLg5mnI/SCHefbpbhfgtnCpi8HDk5uEfgNK84aFU8G9DZzPWAI= 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=Oj0twNyG; arc=none smtp.client-ip=198.175.65.16 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="Oj0twNyG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627195; x=1740163195; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=nx/rpbn5tIj5Y+XhodSjBqWfpjIWIvV6is8OneYevSs=; b=Oj0twNyGf8Qgta8Naju5WFdpqHOinqn/x7Lbqb8unDinzAeW+PyxLSj+ 3JkTAl8HMYn3EHhgeiVYnwJe5i3OOUgI0LPtF6TmMil/XXK+LUn59qkKO gkN4fc/xlmuQsrepRc7PjS3mPLEEqvbclGoHSXXS7iP4Samz8P4+uzCky 89qBsQB/5U/AUTVBzuZYPCSZlyX18/fSyQgGBK8H31fI50zgUwUvYTFG0 6mnsHcfcW3I7dXSbPGMCCruUObWVMn6JEZvArL1uzW56xavqJT4Jy6UzR lLRMGcd+6I49SY5Ne6dG1UfHIpZCWr0xPoFsC+584rLruPyn2cjzaqxbL g==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031846" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031846" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975588" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:55 -0800 Subject: [RFC][PATCH 21/34] x86/cpu: Consolidate CLFLUSH size setting. To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:54 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183954.9A6E5428@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 Right now, cpu_detect() establishes ->x86_clflush_size on each CPU that. supports CLFLUSH. As you might have guessed, that per-cpu value is no longer used. Move the setting to get_cpu_address_sizes() which is only called on the boot CPU. Consolidate all of the ->x86_clflush_size logic into a single helper. This removes the (cap0 & (1<<19) aka X86_FEATURE_CLFLUSH check before reading the CLFLUSH size out of CPUID[1]. Those bits are presumably either 0 or have actual data about CLFLUSH in them. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/cpu/common.c | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) diff -puN arch/x86/kernel/cpu/common.c~later-clflush_size-detect arch/x86/k= ernel/cpu/common.c --- a/arch/x86/kernel/cpu/common.c~later-clflush_size-detect 2024-02-22 10:= 08:58.728856457 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:08:58.732856614 -0800 @@ -935,6 +935,27 @@ static void get_cpu_vendor(struct cpuinf this_cpu =3D &default_cpu; } =20 +static u16 detect_clflush_size(struct cpuinfo_x86 *c) +{ + u16 clflush_size =3D 0; + + if (c->cpuid_level >=3D 0x00000001) { + u32 eax, ebx, ecx, edx; + + cpuid(0x00000001, &eax, &ebx, &ecx, &edx); + + clflush_size =3D ((ebx >> 8) & 0xff) * 8; + } + + if (clflush_size) + return clflush_size; + + /* Return some mostly sane defaults: */ + if (IS_ENABLED(CONFIG_X86_64)) + return 64; + return 32; +} + void cpu_detect(struct cpuinfo_x86 *c) { /* Get vendor name */ @@ -952,11 +973,6 @@ void cpu_detect(struct cpuinfo_x86 *c) c->x86 =3D x86_family(tfms); c->x86_model =3D x86_model(tfms); c->x86_stepping =3D x86_stepping(tfms); - - if (cap0 & (1<<19)) { - if (c =3D=3D &boot_cpu_data) - c->x86_clflush_size =3D ((misc >> 8) & 0xff) * 8; - } } } =20 @@ -1111,17 +1127,17 @@ void get_cpu_address_sizes(struct cpuinf if (IS_ENABLED(CONFIG_X86_64)) { x86_config.phys_bits =3D 36; x86_config.virt_bits =3D 48; - c->x86_clflush_size =3D 64; } else { x86_config.phys_bits =3D 32; x86_config.virt_bits =3D 32; - c->x86_clflush_size =3D 32; =20 if (cpu_has(c, X86_FEATURE_PAE) || cpu_has(c, X86_FEATURE_PSE36)) x86_config.phys_bits =3D 36; } } + c->x86_clflush_size =3D detect_clflush_size(c); + c->x86_cache_bits =3D x86_config.phys_bits; =20 c->x86_cache_alignment =3D x86_clflush_size(); @@ -1827,11 +1843,8 @@ static void identify_cpu(struct cpuinfo_ c->topo.cu_id =3D 0xff; c->topo.llc_id =3D BAD_APICID; c->topo.l2c_id =3D BAD_APICID; -#ifdef CONFIG_X86_64 - c->x86_clflush_size =3D 64; -#else +#ifndef CONFIG_X86_64 c->cpuid_level =3D -1; /* CPUID not detected */ - c->x86_clflush_size =3D 32; #endif memset(&c->x86_capability, 0, sizeof(c->x86_capability)); #ifdef CONFIG_X86_VMX_FEATURE_NAMES _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 00A321493AB for ; Thu, 22 Feb 2024 18:39:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627197; cv=none; b=eRTmVLn5YpnBv/ckSqMVYL8ze8UqiF4/THiXh9HXkb1y3Mwo3K5YcF6YLA+Ag8s0i1AZv6Sh86eiCCsTuRuzOnFmsXwNPkmNZr5d1/1J3n/ScDwrsWUqTxGu9tZ6ZsoHyHDuy2yC83tdcr7ErrXcziwe3XMHQFC9/u4bHxLzB8g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627197; c=relaxed/simple; bh=v85h6zmWNcl6pvDbPStk269PNzaerYIPB3bTofH0JD8=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=TYTHKU2YHt6Y4dxt5D+9OvWdoku2zzidA9rTLHCLGwOOw5sDKL4R7Dj8T6ggpfarrKWvIb5NXLhFa/bgKpX1W1VR6gjLG1d4OOxkh+k9V1Q/lcgqheIFLvDJMCFrdQLHfkAiUw2jpoxEiYBDLnojBoqL6tRiIzx8kMezhw5amG4= 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=KoBNdgtp; arc=none smtp.client-ip=198.175.65.16 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="KoBNdgtp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627197; x=1740163197; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=v85h6zmWNcl6pvDbPStk269PNzaerYIPB3bTofH0JD8=; b=KoBNdgtpJA5rD/teT1upwOP5lmK88rJQK0i326jkoffDMv/vhKLrNs4y rUONFB3DioZkppMzrGUUWD19QOttMufx+2TqvZzwl0hypEifPWaVmowqg TDbp5JM+D+RgmZlqARMSXgzm2Kz7gH41RIOLBfwO1gDTvbu6OU1C5GNVj YRrxvt6qLSXfYKXWh2ewcOA1E8aU477sWa+O+e4KgA4cMHrvgv8JreEUN 2hkA5mq+uD+jBRFjKOBpBc5+z4Van/RyyWomAXdpgiROOpSXILh6oqIBV A+i6Qgwd6uMDYg5dFi9GYb2/JYPEa3b16F0kD4b7EfBnuU1FN8TFSERAP Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031854" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031854" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975605" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:56 -0800 Subject: [RFC][PATCH 22/34] x86/cpu: Move CLFLUSH size into global config To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:55 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183955.292E89F8@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 x86_clflush_size is maintained per-cpu despite being global configuration. Move it to 'x86_config'. Signed-off-by: Dave Hansen --- b/arch/x86/include/asm/processor.h | 4 ++-- b/arch/x86/kernel/cpu/common.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff -puN arch/x86/include/asm/processor.h~bsp-clflush_size arch/x86/includ= e/asm/processor.h --- a/arch/x86/include/asm/processor.h~bsp-clflush_size 2024-02-22 10:08:59= .208875301 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:08:59.212875458 -0800 @@ -148,7 +148,6 @@ struct cpuinfo_x86 { u64 ppin; /* cpuid returned max cores value: */ u16 x86_max_cores; - u16 x86_clflush_size; /* number of cores as seen by the OS: */ u16 booted_cores; /* Index into per_cpu list: */ @@ -191,6 +190,7 @@ struct x86_sys_config { /* Address bits supported by all processors */ u8 phys_bits; u8 virt_bits; + u16 clflush_size; }; =20 extern struct x86_sys_config x86_config; @@ -812,7 +812,7 @@ static inline u8 x86_virt_bits(void) =20 static inline u8 x86_clflush_size(void) { - return boot_cpu_data.x86_clflush_size; + return x86_config.clflush_size; } =20 #endif /* _ASM_X86_PROCESSOR_H */ diff -puN arch/x86/kernel/cpu/common.c~bsp-clflush_size arch/x86/kernel/cpu= /common.c --- a/arch/x86/kernel/cpu/common.c~bsp-clflush_size 2024-02-22 10:08:59.208= 875301 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:08:59.212875458 -0800 @@ -1136,7 +1136,7 @@ void get_cpu_address_sizes(struct cpuinf x86_config.phys_bits =3D 36; } } - c->x86_clflush_size =3D detect_clflush_size(c); + x86_config.clflush_size =3D detect_clflush_size(c); =20 c->x86_cache_bits =3D x86_config.phys_bits; =20 _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 4DAE714CAAA for ; Thu, 22 Feb 2024 18:39:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627198; cv=none; b=LOCgvPOy/FO7U2F62vYuBWYGEkIUwr0rMIyntbwZC86UNT5ACYDDSDwWlWTCZmSQX0OIrhrYi/9/PGDiF4ZdCTB0TacGuxzoxVrnFAho9OQftrG9VXXbI2D81W2Qep2dK5E1Rp55xU41UCmsBXuLfU4a2T7EslHIVKmIclgx69I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627198; c=relaxed/simple; bh=n3sFMUZ3X1KUCYEgfoDu2y2gB7wcsAKIFaZGgsgC84Y=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=oRCtjiAihyg/OsZ9W8hJEW3U6kuea/d88Wy5GN4/UCbWZ7dR+bknrTBzIKfUZJlLNJq1bgvEtqcJcGV5WkfHFy/BYlzwflJNd0lYgGKC3cmtHlUelvoLoACwD8XF0vvl9ejfggEWhgGTQuo926UpnI4MJU/Ho65LsLOoMVHnslo= 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=eyjAmDxK; arc=none smtp.client-ip=198.175.65.16 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="eyjAmDxK" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627198; x=1740163198; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=n3sFMUZ3X1KUCYEgfoDu2y2gB7wcsAKIFaZGgsgC84Y=; b=eyjAmDxKK0w2jJYRy35H/Uh19bb91FVJOeEC1SWWjl22GxpDC01gqpu+ E08uXaUSLt0ULiAbVNRFnOQb4l0OZ3ZHYlt64LaCC6tLiybW7NWS3VXSf 64rJqbZ2T82ZZwTbSjgi2pd2XPs1cqyUD19d5Ih4EQoXiVICUD1+27YKF kkUY0SDjjtC0Cm6aHbLomBWykeoPn8L8tuVUBK3hJPPOwDZsE5+R70vgF MThEztI4UK6OV4W+c00+fcwFb5AfVxvUmpQt8YOl19+1JLvxU0Nj3/UzL VJVhH3r3p7bgMv2rQi6a7Tehc5URX5Qo6pQoZiarmZt15mz8dp29jFpIK A==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="3031861" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="3031861" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="5975614" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa008.jf.intel.com with ESMTP; 22 Feb 2024 10:39:57 -0800 Subject: [RFC][PATCH 23/34] x86/cpu: Move cache alignment configuration to global struct To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:56 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183956.CA91A140@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 It is a tale as old as time: x86_cache_alignment is established and stored per-cpu despite being system-wide. Move it to the global configuration structure. The other values have received _new_ wrappers. But this one already had cache_line_size(). Just use that wrapper. Signed-off-by: Dave Hansen --- b/arch/x86/include/asm/processor.h | 4 ++-- b/arch/x86/kernel/cpu/common.c | 4 ++-- b/arch/x86/kernel/cpu/proc.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff -puN arch/x86/include/asm/processor.h~x86_config-x86_cache_alignment a= rch/x86/include/asm/processor.h --- a/arch/x86/include/asm/processor.h~x86_config-x86_cache_alignment 2024-= 02-22 10:08:59.700894617 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:08:59.708894931 -0800 @@ -137,7 +137,6 @@ struct cpuinfo_x86 { struct cpuinfo_topology topo; /* in KB - valid for CPUS which support this call: */ unsigned int x86_cache_size; - int x86_cache_alignment; /* In bytes */ /* Cache QoS architectural values, valid only on the BSP: */ int x86_cache_max_rmid; /* max index */ int x86_cache_occ_scale; /* scale to bytes */ @@ -191,6 +190,7 @@ struct x86_sys_config { u8 phys_bits; u8 virt_bits; u16 clflush_size; + int cache_alignment; /* in bytes */ }; =20 extern struct x86_sys_config x86_config; @@ -229,7 +229,7 @@ DECLARE_PER_CPU_READ_MOSTLY(struct cpuin =20 extern const struct seq_operations cpuinfo_op; =20 -#define cache_line_size() (boot_cpu_data.x86_cache_alignment) +#define cache_line_size() (x86_config.cache_alignment) =20 extern void cpu_detect(struct cpuinfo_x86 *c); =20 diff -puN arch/x86/kernel/cpu/common.c~x86_config-x86_cache_alignment arch/= x86/kernel/cpu/common.c --- a/arch/x86/kernel/cpu/common.c~x86_config-x86_cache_alignment 2024-02-2= 2 10:08:59.704894774 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:08:59.708894931 -0800 @@ -1140,9 +1140,9 @@ void get_cpu_address_sizes(struct cpuinf =20 c->x86_cache_bits =3D x86_config.phys_bits; =20 - c->x86_cache_alignment =3D x86_clflush_size(); + x86_config.cache_alignment =3D x86_clflush_size(); if (bsp_addr_config.cache_align_mult) - c->x86_cache_alignment *=3D bsp_addr_config.cache_align_mult; + x86_config.cache_alignment *=3D bsp_addr_config.cache_align_mult; =20 /* Do this last to avoid affecting ->x86_cache_bits. */ x86_config.phys_bits -=3D bsp_addr_config.phys_addr_reduction_bits; diff -puN arch/x86/kernel/cpu/proc.c~x86_config-x86_cache_alignment arch/x8= 6/kernel/cpu/proc.c --- a/arch/x86/kernel/cpu/proc.c~x86_config-x86_cache_alignment 2024-02-22 = 10:08:59.704894774 -0800 +++ b/arch/x86/kernel/cpu/proc.c 2024-02-22 10:08:59.708894931 -0800 @@ -131,7 +131,7 @@ static int show_cpuinfo(struct seq_file seq_printf(m, "TLB size\t: %d 4K pages\n", c->x86_tlbsize); #endif seq_printf(m, "clflush size\t: %u\n", x86_clflush_size()); - seq_printf(m, "cache_alignment\t: %d\n", c->x86_cache_alignment); + seq_printf(m, "cache_alignment\t: %d\n", x86_config.cache_alignment); seq_printf(m, "address sizes\t: %u bits physical, %u bits virtual\n", x86_phys_bits(), x86_virt_bits()); =20 _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 9E9E914CAD5 for ; Thu, 22 Feb 2024 18:39:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627201; cv=none; b=pw2P6BXdOlVutFYYov7Nwiefa293at6VCv8I4o8qpZXw1JkOeqfpkrSKRxWTcIqUfvjXRJ14vj+9mmfEUXxIfdaY1C5HWop4dBsxHBPWyXYJ/AWngfGp8J6sRbdVt04Ye1tL/cIEpsuhD5cTkGkRXhR+vFX8lBNp7ULvhNijM04= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627201; c=relaxed/simple; bh=g9iOQCfCOGeDHAxU5yPd22RT/hffnnPIA4rM0xaPx8k=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=d40yDAzKFcBntXLjc2dAOOwaTe+v83+U9nHgmuqSdLg+rixYNq2AuF/Vo90Z23XbapLBPOdhf5+o0yqvUu+C+s9MyJmYNPDvjXoT2RH0VENtnq5qzBgplON/1pA0g1kS4ZYJNFrAsrNldwXY3oUJkO1h0UmSiCHSyMx+rFxtqh0= 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=ZZTrol+e; arc=none smtp.client-ip=192.198.163.9 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="ZZTrol+e" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627199; x=1740163199; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=g9iOQCfCOGeDHAxU5yPd22RT/hffnnPIA4rM0xaPx8k=; b=ZZTrol+ejY0zPk4sWMIbVf27nZdPRbQltD4HlA893sxo8vpSPLPaMj00 5vAoT+EwU8rws8xp710uVW6FYdG2G/g2glku6DoQXOqvJipYXdh0RCbET 4Ubxmy56Q47HxvNA8KBxNIDErmRJyF6E7QeQtaIF2vhjb6iKqtoVIIWWn XQgZZEnhddcxT4B3ESOSqur/wTz/rKuqpSmEpvuL4+ejYgJWkBGxabbKq WJ08me6J5zEOhz2i097xHv72zuwdlomhI1BhyXldraAELOjhD+geCUJUk PjKhH25OskuxhBGWtKaJQ4zr+aD6HG6bDkO6eD72EP2uzFkLB+JS8jom+ A==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="13584547" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="13584547" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="10265228" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa004.jf.intel.com with ESMTP; 22 Feb 2024 10:39:59 -0800 Subject: [RFC][PATCH 24/34] x86/cpu: Establish 'min_cache_bits' configuration To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:58 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183958.F5A0812A@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 Continue moving towards a setup where code never tweaks 'boot_cpu_data'. Code must establish their intent in 'x86_addr_config' and then later code will use that config information to establish the system-wide config. The L1TF wants to tweak x86_cache_bits. Let it do this, but move the code away from bugs.c so that ti can be easily called earlier en boot. Signed-off-by: Dave Hansen --- b/arch/x86/include/asm/processor.h | 6 +++++ b/arch/x86/kernel/cpu/bugs.c | 41 --------------------------------= ----- b/arch/x86/kernel/cpu/common.c | 2 + b/arch/x86/kernel/cpu/intel.c | 40 ++++++++++++++++++++++++++++++++= ++++ 4 files changed, 48 insertions(+), 41 deletions(-) diff -puN arch/x86/include/asm/processor.h~bsp-min_cache_bits arch/x86/incl= ude/asm/processor.h --- a/arch/x86/include/asm/processor.h~bsp-min_cache_bits 2024-02-22 10:09:= 00.220915031 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:09:00.224915188 -0800 @@ -177,6 +177,12 @@ struct x86_addr_config { * will take place at a more coarse granularity. */ u8 cache_align_mult; + + /* + * Specify a floor for the number of bits that the CPU + * caches comprehend. Used only for L1TF mitigation. + */ + u8 min_cache_bits; }; =20 /* diff -puN arch/x86/kernel/cpu/bugs.c~bsp-min_cache_bits arch/x86/kernel/cpu= /bugs.c --- a/arch/x86/kernel/cpu/bugs.c~bsp-min_cache_bits 2024-02-22 10:09:00.220= 915031 -0800 +++ b/arch/x86/kernel/cpu/bugs.c 2024-02-22 10:09:00.224915188 -0800 @@ -2237,45 +2237,6 @@ EXPORT_SYMBOL_GPL(l1tf_mitigation); enum vmx_l1d_flush_state l1tf_vmx_mitigation =3D VMENTER_L1D_FLUSH_AUTO; EXPORT_SYMBOL_GPL(l1tf_vmx_mitigation); =20 -/* - * These CPUs all support 44bits physical address space internally in the - * cache but CPUID can report a smaller number of physical address bits. - * - * The L1TF mitigation uses the top most address bit for the inversion of - * non present PTEs. When the installed memory reaches into the top most - * address bit due to memory holes, which has been observed on machines - * which report 36bits physical address bits and have 32G RAM installed, - * then the mitigation range check in l1tf_select_mitigation() triggers. - * This is a false positive because the mitigation is still possible due to - * the fact that the cache uses 44bit internally. Use the cache bits - * instead of the reported physical bits and adjust them on the affected - * machines to 44bit if the reported bits are less than 44. - */ -static void override_cache_bits(struct cpuinfo_x86 *c) -{ - if (c->x86 !=3D 6) - return; - - switch (c->x86_model) { - case INTEL_FAM6_NEHALEM: - case INTEL_FAM6_WESTMERE: - case INTEL_FAM6_SANDYBRIDGE: - case INTEL_FAM6_IVYBRIDGE: - case INTEL_FAM6_HASWELL: - case INTEL_FAM6_HASWELL_L: - case INTEL_FAM6_HASWELL_G: - case INTEL_FAM6_BROADWELL: - case INTEL_FAM6_BROADWELL_G: - case INTEL_FAM6_SKYLAKE_L: - case INTEL_FAM6_SKYLAKE: - case INTEL_FAM6_KABYLAKE_L: - case INTEL_FAM6_KABYLAKE: - if (c->x86_cache_bits < 44) - c->x86_cache_bits =3D 44; - break; - } -} - static void __init l1tf_select_mitigation(void) { u64 half_pa; @@ -2288,8 +2249,6 @@ static void __init l1tf_select_mitigatio else if (cpu_mitigations_auto_nosmt()) l1tf_mitigation =3D L1TF_MITIGATION_FLUSH_NOSMT; =20 - override_cache_bits(&boot_cpu_data); - switch (l1tf_mitigation) { case L1TF_MITIGATION_OFF: case L1TF_MITIGATION_FLUSH_NOWARN: diff -puN arch/x86/kernel/cpu/common.c~bsp-min_cache_bits arch/x86/kernel/c= pu/common.c --- a/arch/x86/kernel/cpu/common.c~bsp-min_cache_bits 2024-02-22 10:09:00.2= 20915031 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:09:00.228915345 -0800 @@ -1139,6 +1139,8 @@ void get_cpu_address_sizes(struct cpuinf x86_config.clflush_size =3D detect_clflush_size(c); =20 c->x86_cache_bits =3D x86_config.phys_bits; + if (c->x86_cache_bits < bsp_addr_config.min_cache_bits) + c->x86_cache_bits =3D bsp_addr_config.min_cache_bits; =20 x86_config.cache_alignment =3D x86_clflush_size(); if (bsp_addr_config.cache_align_mult) diff -puN arch/x86/kernel/cpu/intel.c~bsp-min_cache_bits arch/x86/kernel/cp= u/intel.c --- a/arch/x86/kernel/cpu/intel.c~bsp-min_cache_bits 2024-02-22 10:09:00.22= 4915188 -0800 +++ b/arch/x86/kernel/cpu/intel.c 2024-02-22 10:09:00.228915345 -0800 @@ -395,6 +395,44 @@ detect_keyid_bits: return keyid_bits; } =20 +/* + * These CPUs all support 44bits physical address space internally in the + * cache but CPUID can report a smaller number of physical address bits. + * + * The L1TF mitigation uses the top most address bit for the inversion of + * non present PTEs. When the installed memory reaches into the top most + * address bit due to memory holes, which has been observed on machines + * which report 36bits physical address bits and have 32G RAM installed, + * then the mitigation range check in l1tf_select_mitigation() triggers. + * This is a false positive because the mitigation is still possible due to + * the fact that the cache uses 44bit internally. Use the cache bits + * instead of the reported physical bits and adjust them on the affected + * machines to 44bit if the reported bits are less than 44. + */ +static void set_min_cache_bits(struct cpuinfo_x86 *c) +{ + if (c->x86 !=3D 6) + return; + + switch (c->x86_model) { + case INTEL_FAM6_NEHALEM: + case INTEL_FAM6_WESTMERE: + case INTEL_FAM6_SANDYBRIDGE: + case INTEL_FAM6_IVYBRIDGE: + case INTEL_FAM6_HASWELL: + case INTEL_FAM6_HASWELL_L: + case INTEL_FAM6_HASWELL_G: + case INTEL_FAM6_BROADWELL: + case INTEL_FAM6_BROADWELL_G: + case INTEL_FAM6_SKYLAKE_L: + case INTEL_FAM6_SKYLAKE: + case INTEL_FAM6_KABYLAKE_L: + case INTEL_FAM6_KABYLAKE: + bsp_addr_config.min_cache_bits =3D 44; + break; + } +} + static void bsp_init_intel(struct cpuinfo_x86 *c) { int keyid_bits =3D 0; @@ -418,6 +456,8 @@ static void bsp_init_intel(struct cpuinf /* Netburst reports 64 bytes clflush size, but does IO in 128 bytes */ if (c->x86 =3D=3D 15) bsp_addr_config.cache_align_mult =3D 2; + + set_min_cache_bits(c); } =20 #ifdef CONFIG_X86_32 _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 51D1714DFCA for ; Thu, 22 Feb 2024 18:40:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627202; cv=none; b=EPXBxyrifDtEHKdIM4vtVYrWeLu7FLMurkP5iQzPd8Z2v2BJu3Frt3kKhr3ZBUHodrkKsMXApst9YmQc1HKItdcvk1ULKqlbZDSTXt2CPv7IhDTiwZUr+u5JgahISl8bfplChT5HkuTm26kT7s/6aK9o0RFGKU4EpsJEv5gcq0o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627202; c=relaxed/simple; bh=EaW9U2GVh2a4ff8twfadEFuAzYEJkIYZvc+7BRdXeIw=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=WppTmIgQ4cwNntKVBAixtwTc7zcAQw7ffuIrnIHbJBk8/09QrjE8hLfV8I1vTiFddIO0O6o0BNeWtZXOA5+mBt40sPufI1VGtv15LAdTWAFxLTW0FuDYfjR7MdYLZtaFilPVmkBJMnn4GbxPMDZ4HxYy1Hgx09U6C9vlihKQ6Ao= 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=P+0laI0Z; arc=none smtp.client-ip=192.198.163.9 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="P+0laI0Z" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627201; x=1740163201; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=EaW9U2GVh2a4ff8twfadEFuAzYEJkIYZvc+7BRdXeIw=; b=P+0laI0ZOC2XmHvMvquboye3X1GAbP46sEVPpfck1TtjvfFQP1XWEF+B lF3ynbaMTxBeGRtWKtV+myMc4Rj7hPLzZMWCEJuWlRyLPlPwMHAevc4u6 8fNH0NzFL0l0G4UpStfqOnp+g0bMLDBf73qMdqCqy/RBE29im0hH8MxmU +hOydID5OJdCxHrf6YnCidYunJmzI3wlVlKvBgB+LaYhACUnWYtTnMR6Q 36EK2ORrwYScGbpBT0ehwdUks2OYgVNrXsNQ7xRSlOHSnhfdrt+hwveO9 L56JT+O1j0ehbi9Eb+y94k+sFp3d8VgEffsiMjkS7UrYQIl4x8J1sAOEB Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="13584552" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="13584552" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:39:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="10265229" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa004.jf.intel.com with ESMTP; 22 Feb 2024 10:40:00 -0800 Subject: [RFC][PATCH 25/34] x86/cpu: Move cache bits to global config To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:39:59 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222183959.7061C5F3@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 x86_cache_bits is established and stored per-cpu despite being system-wide. Move it from 'struct cpuinfo_x86' to 'x86_config' and give it a helper. Signed-off-by: Dave Hansen --- b/arch/x86/include/asm/processor.h | 10 +++++++--- b/arch/x86/kernel/cpu/common.c | 8 ++++---- b/arch/x86/kvm/mmu/spte.c | 6 +++--- 3 files changed, 14 insertions(+), 10 deletions(-) diff -puN arch/x86/include/asm/processor.h~config-cache_bits arch/x86/inclu= de/asm/processor.h --- a/arch/x86/include/asm/processor.h~config-cache_bits 2024-02-22 10:09:0= 0.768936544 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:09:00.772936701 -0800 @@ -154,8 +154,6 @@ struct cpuinfo_x86 { /* Is SMT active on this core? */ bool smt_active; u32 microcode; - /* Address space bits used by the cache internally */ - u8 x86_cache_bits; unsigned initialized : 1; } __randomize_layout; =20 @@ -195,6 +193,7 @@ struct x86_sys_config { /* Address bits supported by all processors */ u8 phys_bits; u8 virt_bits; + u8 cache_bits; u16 clflush_size; int cache_alignment; /* in bytes */ }; @@ -241,7 +240,7 @@ extern void cpu_detect(struct cpuinfo_x8 =20 static inline unsigned long long l1tf_pfn_limit(void) { - return BIT_ULL(boot_cpu_data.x86_cache_bits - 1 - PAGE_SHIFT); + return BIT_ULL(x86_config.cache_bits - 1 - PAGE_SHIFT); } =20 extern void early_cpu_init(void); @@ -816,6 +815,11 @@ static inline u8 x86_virt_bits(void) return x86_config.virt_bits; } =20 +static inline u8 x86_cache_bits(void) +{ + return x86_config.cache_bits; +} + static inline u8 x86_clflush_size(void) { return x86_config.clflush_size; diff -puN arch/x86/kernel/cpu/common.c~config-cache_bits arch/x86/kernel/cp= u/common.c --- a/arch/x86/kernel/cpu/common.c~config-cache_bits 2024-02-22 10:09:00.76= 8936544 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:09:00.772936701 -0800 @@ -1138,15 +1138,15 @@ void get_cpu_address_sizes(struct cpuinf } x86_config.clflush_size =3D detect_clflush_size(c); =20 - c->x86_cache_bits =3D x86_config.phys_bits; - if (c->x86_cache_bits < bsp_addr_config.min_cache_bits) - c->x86_cache_bits =3D bsp_addr_config.min_cache_bits; + x86_config.cache_bits =3D x86_config.phys_bits; + if (x86_config.cache_bits < bsp_addr_config.min_cache_bits) + x86_config.cache_bits =3D bsp_addr_config.min_cache_bits; =20 x86_config.cache_alignment =3D x86_clflush_size(); if (bsp_addr_config.cache_align_mult) x86_config.cache_alignment *=3D bsp_addr_config.cache_align_mult; =20 - /* Do this last to avoid affecting ->x86_cache_bits. */ + /* Do this last to avoid affecting '.cache_bits'. */ x86_config.phys_bits -=3D bsp_addr_config.phys_addr_reduction_bits; } =20 diff -puN arch/x86/kvm/mmu/spte.c~config-cache_bits arch/x86/kvm/mmu/spte.c --- a/arch/x86/kvm/mmu/spte.c~config-cache_bits 2024-02-22 10:09:00.7729367= 01 -0800 +++ b/arch/x86/kvm/mmu/spte.c 2024-02-22 10:09:00.772936701 -0800 @@ -470,12 +470,12 @@ void kvm_mmu_reset_all_pte_masks(void) shadow_nonpresent_or_rsvd_mask =3D 0; low_phys_bits =3D x86_phys_bits(); if (boot_cpu_has_bug(X86_BUG_L1TF) && - !WARN_ON_ONCE(boot_cpu_data.x86_cache_bits >=3D + !WARN_ON_ONCE(x86_cache_bits() >=3D 52 - SHADOW_NONPRESENT_OR_RSVD_MASK_LEN)) { - low_phys_bits =3D boot_cpu_data.x86_cache_bits + low_phys_bits =3D x86_cache_bits() - SHADOW_NONPRESENT_OR_RSVD_MASK_LEN; shadow_nonpresent_or_rsvd_mask =3D - rsvd_bits(low_phys_bits, boot_cpu_data.x86_cache_bits - 1); + rsvd_bits(low_phys_bits, x86_cache_bits() - 1); } =20 shadow_nonpresent_or_rsvd_lower_gfn_mask =3D _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 B19DA140E3F for ; Thu, 22 Feb 2024 18:40:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627203; cv=none; b=p3lwDtxFhXqhpE9QEpuXZ0qFerBxxpKmGRA+Kg2IeAGG2YFW+BHCo08TcZo5yvJ3AGimADiU8YiCksVt0DO7wSoo4WzfPg/4wZA6EQQux8w8UBNeFTpbrTxq4VdQxXzjCLJXxVIOg03eHPjFY21DvaZu/PnacZ+801n1Uy+DPlk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627203; c=relaxed/simple; bh=jlRQT407YyuEjgIgy+f+wvbminlLl1hPvuPvmjlH09Y=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=WOWrRakq714HcGhhrxxyGSHMrV+EEP7lhpl+0pd6j1O1HElUJVlmxvBiMvBoZHaSVdsRLiHsQgStTOawhFeAVm+425nMlc7mgweDzFkV+aZgqy13yB/2TjJqdyWsWc5PxxqePZJjoaEjmvMSm8osPI/UInBtRkf0+CRglKcEkCY= 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=bETgXOOG; arc=none smtp.client-ip=192.198.163.9 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="bETgXOOG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627201; x=1740163201; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=jlRQT407YyuEjgIgy+f+wvbminlLl1hPvuPvmjlH09Y=; b=bETgXOOGtYZCsTAscMo1LIy7QXRlyKmhmJpCffzlJ46I0L4NbNnk2lKO wUdNUIObaNU6EGuMy/clQXIR2FTllf+quUfJjT+fAUpzQmB/2xkjZHYBW 3T6VHtpyU2hAI1UqEjttXKmjMlHPOJFA3UpGmIZoiN7MPCQLbuf69f+FE vR5TYIC8CIZ3vcFGhAab+5JG5RCObs7fZy/iWHMZPqWIFx3kHOFhrol5x //rVs6wZUEjzamXJAXMXHBjFRTE+k5YIqWvAwucxryCNOSdYjbxxf9fya GKmiOsVpun/hmVZ1246SNDFzha1JcjrzlTH5OLLPMNEjdRGAlcuzBjCXI w==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="13584558" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="13584558" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:40:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="10265242" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa004.jf.intel.com with ESMTP; 22 Feb 2024 10:40:01 -0800 Subject: [RFC][PATCH 26/34] x86/cpu: Zap superfluous get_cpu_address_sizes() To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:40:00 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222184000.F74060D0@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 All of the 'x86_config' state is established by the boot CPU long before generic_identify(). There is no need to call get_cpu_address_sizes() again. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/cpu/common.c | 2 -- 1 file changed, 2 deletions(-) diff -puN arch/x86/kernel/cpu/common.c~zap-extra-get_cpu_address_sizes arch= /x86/kernel/cpu/common.c --- a/arch/x86/kernel/cpu/common.c~zap-extra-get_cpu_address_sizes 2024-02-= 22 10:09:01.292957116 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:09:01.296957273 -0800 @@ -1770,8 +1770,6 @@ static void generic_identify(struct cpui =20 get_cpu_cap(c); =20 - get_cpu_address_sizes(c); - if (c->cpuid_level >=3D 0x00000001) { c->topo.initial_apicid =3D (cpuid_ebx(1) >> 24) & 0xFF; #ifdef CONFIG_X86_32 _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 EB6FE14DFDD for ; Thu, 22 Feb 2024 18:40:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627204; cv=none; b=htOkfSd5kv8HgVVuB5jdhXyxRtms76e3flz/Lf51+HwGoXikIQUOZdmqeFo3uS6kjlnRtKvSZ4SW4ySnoMMzW+TZQHa/D96oXc7/tqMULLphHEUdDOyTCd0yU7RPvwN6GTmUPe+HnCSt5M0Ub8cK5j8Gt0seibd7m/rXCMW7Kq0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627204; c=relaxed/simple; bh=M0K0p1YY8ZD9RWKhulCbsPvnuM9T8SM1JcaqD9ukN24=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=MB8XHhbi/TN9S1r6wzihN1Gi4QM+VKDcZSpZsofOAyfVO4oLnOoymLZSPbOqFqjunvTtoIyoQxIDHUsyn3uxFRw2cBApTZhRFqj9CYgBTYrmhBAWIX1BXd/HtH0TCzTAuIUahgAGHm6mDJxMQ1Ro98ZpJZXSzSibjn3KgyC5PeM= 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=nYTRWxUA; arc=none smtp.client-ip=192.198.163.9 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="nYTRWxUA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627203; x=1740163203; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=M0K0p1YY8ZD9RWKhulCbsPvnuM9T8SM1JcaqD9ukN24=; b=nYTRWxUAUZj67bdyj1gOL3IV5Y8q429vWrDRp1B6lc+iJEWHNBLVknj6 Z8TYQ61UuZztv7zNmeE16CA+1MJ/LE5aDq3XeS/1d777wfOZSLq7/evOW AYdcT+B/Zt66VhGd2UM0j5bCceQ7zQBYE3mN5iDorDKlJlLJCtnVGHE6A 7429yNpV+gIbAq0zM3a2lLfaq4DEi72kpDa+8XJQwPaQKRIUpcpROjV06 2LoBgzT20tAR3vyYekdQajXRB9JpnVK3kWheOwhAh2Xhs7LYWrrZR//N8 VwCPnhONtF5tXhLKjRrVDxDt4UrMNov0NvYYOB3EiVtZdQIyC2vLNuEKp A==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="13584565" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="13584565" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:40:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="10265249" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa004.jf.intel.com with ESMTP; 22 Feb 2024 10:40:02 -0800 Subject: [RFC][PATCH 27/34] x86/cpu: Enforce read-only x86_config state (lightly) To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:40:02 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222184002.690F68EF@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 Part of the reason that this all turned into such a mess is that there were no rules around when 'struct cpuinfo_x86' was written. It was (and is) just a free-for-all. Establish that 'x86_config' has two phases of its lifetime: an C_INITIALIZING phase where it can be written and a later C_FINALIZED stage where it can only be read. It is simple to audit the fact that this state transition happens just where the comment says it should be. Check that the config is C_FINALIZED in each of the wrappers that read a 'x86_config' value. If something reads too early, stash some information to the caller so that it can spit out a warning later. This goofy stash-then-warn construct is necessary here because any hapless readers are likely to be in a spot where they can not easily WARN() themselves, like the early Xen PV boot that's caused so many problems. This also moves one x86_clflush_size() reference over to the more direct x86_config.cache_alignment because otherwise it would trip the !C_FINALIZED check. Signed-off-by: Dave Hansen --- b/arch/x86/include/asm/processor.h | 22 ++++++++++++++++++++++ b/arch/x86/kernel/cpu/common.c | 5 ++++- b/arch/x86/kernel/setup.c | 7 +++++++ 3 files changed, 33 insertions(+), 1 deletion(-) diff -puN arch/x86/include/asm/processor.h~x86_config-finalize arch/x86/inc= lude/asm/processor.h --- a/arch/x86/include/asm/processor.h~x86_config-finalize 2024-02-22 10:09= :01.772975960 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:09:01.780976274 -0800 @@ -183,6 +183,11 @@ struct x86_addr_config { u8 min_cache_bits; }; =20 +enum x86_sys_config_state { + C_INITIALIZING, + C_FINALIZED +}; + /* * System-wide configuration that is shared by all processors. * @@ -190,6 +195,9 @@ struct x86_addr_config { * modified after that. */ struct x86_sys_config { + enum x86_sys_config_state conf_state; + void *early_reader; + /* Address bits supported by all processors */ u8 phys_bits; u8 virt_bits; @@ -805,23 +813,37 @@ static inline void weak_wrmsr_fence(void alternative("mfence; lfence", "", ALT_NOT(X86_FEATURE_APIC_MSRS_FENCE)); } =20 +static inline void read_x86_config(void) +{ + if (x86_config.conf_state =3D=3D C_FINALIZED) + return; + + /* Only record the first one: */ + if (!x86_config.early_reader) + x86_config.early_reader =3D __builtin_return_address(0); +} + static inline u8 x86_phys_bits(void) { + read_x86_config(); return x86_config.phys_bits; } =20 static inline u8 x86_virt_bits(void) { + read_x86_config(); return x86_config.virt_bits; } =20 static inline u8 x86_cache_bits(void) { + read_x86_config(); return x86_config.cache_bits; } =20 static inline u8 x86_clflush_size(void) { + read_x86_config(); return x86_config.clflush_size; } =20 diff -puN arch/x86/kernel/cpu/common.c~x86_config-finalize arch/x86/kernel/= cpu/common.c --- a/arch/x86/kernel/cpu/common.c~x86_config-finalize 2024-02-22 10:09:01.= 776976117 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:09:01.780976274 -0800 @@ -1114,6 +1114,9 @@ void get_cpu_address_sizes(struct cpuinf u32 eax, ebx, ecx, edx; bool vp_bits_from_cpuid =3D true; =20 + WARN_ON_ONCE(x86_config.conf_state > C_INITIALIZING); + x86_config.conf_state =3D C_INITIALIZING; + if (!cpu_has(c, X86_FEATURE_CPUID) || (c->extended_cpuid_level < 0x80000008)) vp_bits_from_cpuid =3D false; @@ -1142,7 +1145,7 @@ void get_cpu_address_sizes(struct cpuinf if (x86_config.cache_bits < bsp_addr_config.min_cache_bits) x86_config.cache_bits =3D bsp_addr_config.min_cache_bits; =20 - x86_config.cache_alignment =3D x86_clflush_size(); + x86_config.cache_alignment =3D x86_config.clflush_size; if (bsp_addr_config.cache_align_mult) x86_config.cache_alignment *=3D bsp_addr_config.cache_align_mult; =20 diff -puN arch/x86/kernel/setup.c~x86_config-finalize arch/x86/kernel/setup= .c --- a/arch/x86/kernel/setup.c~x86_config-finalize 2024-02-22 10:09:01.77697= 6117 -0800 +++ b/arch/x86/kernel/setup.c 2024-02-22 10:09:01.780976274 -0800 @@ -762,7 +762,14 @@ void __init setup_arch(char **cmdline_p) olpc_ofw_detect(); =20 idt_setup_early_traps(); + early_cpu_init(); + + /* Ensure no readers snuck in before the config was finished: */ + WARN_ONCE(x86_config.early_reader, "x86_config.early_reader: %pS\n", + x86_config.early_reader); + x86_config.conf_state =3D C_FINALIZED; + jump_label_init(); static_call_init(); early_ioremap_init(); _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 9967B14EFC1 for ; Thu, 22 Feb 2024 18:40:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627207; cv=none; b=ace7s/pwIDPx9XHxTqoAaMqH5ynFMimI6ew2J6TSZB1qKxDqWVF330fEi3/Of2Rd+OrrsMZ76u+g9yGC69SGl58Qy/2MDxEzG5L3l9eHtstT7CGneqABCAl9W/jZzkoz4dDKV3deXpkJiwLSj+5QwObb1mhutueuypANC/YQVMY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627207; c=relaxed/simple; bh=7kh29fKzq0nBKTNuMbdWSslJMi85X1GnHn7bPcB2f/k=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=oNi3OSZPCL8mViqC8Y+kFEtXXDyX+PWM1gKjzzoziTAsGiFWo/MMKZe2jlzxjjhfR165HYeXwNChj53nPVY+rJKw/rKyF3Gjtr/dBVLvV2zD1GDfQGSDx0/PfHFWGaeTIHqgVYUmjCnuEGDHHanbnNSFsQsfotQ3F4mq8p+r24A= 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=exeNTwdS; arc=none smtp.client-ip=192.198.163.9 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="exeNTwdS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627204; x=1740163204; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=7kh29fKzq0nBKTNuMbdWSslJMi85X1GnHn7bPcB2f/k=; b=exeNTwdS9yKPFJ9FhrrLAFu7VL6ASLvIQVkNJ0O3eNtWM0nI8+CIm/A7 UyASqq97PmlYggpK6O2oQpQGodTGTd0sRFGEcEVN2Tzuz/9K8YuaFNpzo WVzTttYicNTflB68OtzKNJAfTpS0TdcOeTtqFAq0GS99NoB/Vma57ohvz TSE68dc7+GN2ZtteOy+DbmkDpdMj0GBlgh325+L6WUcZfIZz1iUrSypSa XqCgYH6IquXnxoP4BU//dh9Ae0DywbhnPQz5llvmctktp8Y85THlB5r7G VXRNBlzAWhUHEVMfOC4iEuBknt3Mg9ggT2MIA83nQvT3rQEiJM6h3wsfQ A==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="13584574" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="13584574" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:40:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="10265258" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa004.jf.intel.com with ESMTP; 22 Feb 2024 10:40:04 -0800 Subject: [RFC][PATCH 28/34] x86/cpu: Return sane defaults for early x86_config reads To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:40:03 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222184003.85CE26B6@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 *If* an unexpected user tries to read 'x86_config' before it is C_FINALIZED and valid, it will likely get 0's or other garbage. Those values often cause the user to crash before they can get a nice message out to the console. Provide some mostly random but unlikely-to-crash-the-caller values. Signed-off-by: Dave Hansen --- b/arch/x86/include/asm/processor.h | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff -puN arch/x86/include/asm/processor.h~x86_config-defaults arch/x86/inc= lude/asm/processor.h --- a/arch/x86/include/asm/processor.h~x86_config-defaults 2024-02-22 10:09= :02.280995903 -0800 +++ b/arch/x86/include/asm/processor.h 2024-02-22 10:09:02.280995903 -0800 @@ -813,37 +813,57 @@ static inline void weak_wrmsr_fence(void alternative("mfence; lfence", "", ALT_NOT(X86_FEATURE_APIC_MSRS_FENCE)); } =20 -static inline void read_x86_config(void) +static inline int read_x86_config(void) { if (x86_config.conf_state =3D=3D C_FINALIZED) - return; + return 0; =20 /* Only record the first one: */ if (!x86_config.early_reader) x86_config.early_reader =3D __builtin_return_address(0); + + return -EINVAL; } =20 +/* + * These _should_ not be called until x86_config is C_FINALIZED. + * In the case that they are, two things will happen: + * 1. The first caller will get the call site recorded in + * 'early_reader' which will trigger a warning later in + * boot. + * 2. A moderately sane hard-coded default value will be provided. + * The entire intent of this value is to let things limp along + * until the warning can spit out. + */ static inline u8 x86_phys_bits(void) { - read_x86_config(); + if (read_x86_config()) + return 52; + return x86_config.phys_bits; } =20 static inline u8 x86_virt_bits(void) { - read_x86_config(); + if (read_x86_config()) + return IS_ENABLED(CONFIG_X86_64) ? 57 : 32; + return x86_config.virt_bits; } =20 static inline u8 x86_cache_bits(void) { - read_x86_config(); + if (read_x86_config()) + return 52; + return x86_config.cache_bits; } =20 static inline u8 x86_clflush_size(void) { - read_x86_config(); + if (read_x86_config()) + return 64; + return x86_config.clflush_size; } =20 _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 255D714EFC7 for ; Thu, 22 Feb 2024 18:40:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627206; cv=none; b=XD91gesTGmsuw+5xf+3ZBixAfUl8H30mGE0oC3t0h1k1/CvyKIFq39hsrKw5OopGLZPp8m1c+WP/xwqW1U5zjpuByZcBIt2X2S5nZymtxYH08IKR8mf0Zt3FgCvf8MrB4rjdj4yXXMV3y36FhRhIYYRhIanzvzIFfs0YYQJ0tDw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627206; c=relaxed/simple; bh=qBn4TiOyJK73Ejv38vlOE4n5SWGEzB9iLnbLIjuNbPw=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=D7VXxwZEmGXNRggk+4kh4ZM70MYBbRFT9LvrmMbrmQ1jBcf5p5LdAnzg6eUFYlnFMK5bRPjuQfOHqN0+OlxxRe0S4yGDw950Ii3JdVz3h0EkLUEU/ut+a93RJQiaNJMrTJ0L0HvELhuTvjyqiNthgdcI5sOcDm3t0NsyvjTeafM= 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=mQHvS9Xa; arc=none smtp.client-ip=192.198.163.9 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="mQHvS9Xa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627205; x=1740163205; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=qBn4TiOyJK73Ejv38vlOE4n5SWGEzB9iLnbLIjuNbPw=; b=mQHvS9Xa6qEW9scb65ws0Dfmfjzyi19XNkUPG1WOJdKoocVSupuWbKta QeMuvy+v1kq5M1//ABn8JFr3NAKVKOs87RqB39h+OPPuwaCnSSI/Knvrf Wt05TUk1VOxhIWVD46yKfe8B/uVBDaLBQVcOkhHZS+dPM1spTz3i/GvpV hrhXRzcqMhdyIsAfpeINR9MkyhOwJEAk+cMRPuNto6Zn2ot1AjmWhFTgE ZIGmj5XV8RNVEWlydJAw4DS1UOQ7qAk7L1G2Bx1dAKRuyBgv/7rCatqiR 9zmhgKWCz/Kw40bFI+tNyZZpflAhYxE9S+B8Sv81tplUnx7pah6D6JRye Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="13584579" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="13584579" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:40:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="10265264" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa004.jf.intel.com with ESMTP; 22 Feb 2024 10:40:05 -0800 Subject: [RFC][PATCH 29/34] x86/xen: Remove extra get_cpu_address_sizes() call To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:40:04 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222184004.C5E65C3C@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 PV should now be avoiding reading 'x86_config' at all due to previous fixes. Even if something was missed, it should now get sane values *and* be able to survive long enough to get a warning out later in boot. Remove the belt-and-suspenders call to get_cpu_address_sizes(). Signed-off-by: Dave Hansen --- b/arch/x86/xen/enlighten_pv.c | 3 --- 1 file changed, 3 deletions(-) diff -puN arch/x86/xen/enlighten_pv.c~xen-remove-early-addr_size-fun arch/x= 86/xen/enlighten_pv.c --- a/arch/x86/xen/enlighten_pv.c~xen-remove-early-addr_size-fun 2024-02-22= 10:09:02.753014433 -0800 +++ b/arch/x86/xen/enlighten_pv.c 2024-02-22 10:09:02.757014590 -0800 @@ -1386,9 +1386,6 @@ asmlinkage __visible void __init xen_sta */ xen_setup_gdt(0); =20 - /* Determine virtual and physical address sizes */ - get_cpu_address_sizes(&boot_cpu_data); - /* Let's presume PV guests always boot on vCPU with id 0. */ per_cpu(xen_vcpu_id, 0) =3D 0; =20 _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 4436A14038D for ; Thu, 22 Feb 2024 18:40:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627210; cv=none; b=q+6eX3zO+W9Auvl3CdYO3MBpYn6YurAGrbuK2LQbeiU0i1kkelWP62RaxX/b9nHyZono+artC41vpaCCx8hvHZgWCfj1SPqlax70ejMkVNFA6ACiEBhu8+7qDm9u99dn5FFiZuV7FDz4KGb+10xvOeoNyRfkY+5yu1zmlD2BSC8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627210; c=relaxed/simple; bh=IHq53bWUd8zFRS3i8EHUWcDqCt/OSX6cwnyJtJ5m0oY=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=Hj5AA2Hyju5+lUprAj3f4kWqhcaS8yjD04HPWXvz7l98aWE+k269fZFhozuubNUwoi5rnRBLDZ/q9hWYysRn+xeI3Di0kfhHGou5Ifnd2TjN+JgrIq0TLa+SUosubSySVZJuNy2SI90/9TBJUT5MrUq5EL2SURy/eXxfDqWhB1M= 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=Y02G1hto; arc=none smtp.client-ip=192.198.163.9 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="Y02G1hto" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627208; x=1740163208; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=IHq53bWUd8zFRS3i8EHUWcDqCt/OSX6cwnyJtJ5m0oY=; b=Y02G1htoWg/nmJknhefWTrk61U14CuT4uQx9ZoF04Iw1bVaLof3lPXCC lbEeDY12YBliUCWq77qV7wDHNmkzRbT18tU49r+ua+cuznC7LolgXBUBj DFGaeFP+2dBRdk9jAiNycfZfeoZNQnrFFu6UwIfIzaj3C0qFlU1ra3pPd 8vudXSMIE257s/LkFppLkC3bRuu4VBWYzhQRLPstEEFy88dvgj/lVFM5r oWoCgGN0y8VTBhO8+pKIGCCfFAyLq50LOis4QPxlfV/BfYjwcnMIWBa9M 1kM/3nsmuBtYJ47t/qjYJd7sTW++whmARAJ4W0H44EFl70cZh5ellraQY g==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="13584585" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="13584585" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:40:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="10265271" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa004.jf.intel.com with ESMTP; 22 Feb 2024 10:40:06 -0800 Subject: [RFC][PATCH 30/34] x86/cpu/centaur: Mark BSP init function as __init To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:40:05 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222184005.87229530@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 boot CPU is obviously not initialized during normal system runtime and its code can be __init. This prevents a warning once 'bsp_addr_config' gets marked __init. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/cpu/centaur.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN arch/x86/kernel/cpu/centaur.c~bsp_init_centaur-__init arch/x86/ke= rnel/cpu/centaur.c --- a/arch/x86/kernel/cpu/centaur.c~bsp_init_centaur-__init 2024-02-22 10:0= 9:03.237033434 -0800 +++ b/arch/x86/kernel/cpu/centaur.c 2024-02-22 10:09:03.237033434 -0800 @@ -213,7 +213,7 @@ static void init_centaur(struct cpuinfo_ init_ia32_feat_ctl(c); } =20 -static void bsp_init_centaur(struct cpuinfo_x86 *c) +static void __init bsp_init_centaur(struct cpuinfo_x86 *c) { if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) bsp_addr_config.cache_align_mult =3D 2; _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 878BC14F96A for ; Thu, 22 Feb 2024 18:40:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627210; cv=none; b=EMQbirii/3B7ofvwr/UpMRW4y+CqWy5PRDNoACqjYEEUJGdnsIvea3KdQyNok3Ooa6cIlMKedyhvF2lk4x4fNljjrk0yrYcSt2m5iBoakQkYmACGx6S9Nx7qckywgVuY0TqRwP0lrM6CnQYg/3XFAx85frvc8so3JIpCEyvqYAo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627210; c=relaxed/simple; bh=V0nhZmX+DNdyizRXt1fC0+DFHcTx60c+hJHBb5KG2wU=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=Ci4tb2lCNPieh6msZjkRG9ov70My+4gO/uZm52/GOh3D/aZycZxY6FF7O5epmDNvzL5UqutUTExXS571Lc6+gp3a4SI1nfeaaI1oIihYTR74Xn4L3iRkODegZw8/LkZX76jGmDLlhjt9WtyaWEr/SXptQXx98PaIsdXc/vwfn/4= 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=HfjcCjsp; arc=none smtp.client-ip=192.198.163.9 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="HfjcCjsp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627208; x=1740163208; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=V0nhZmX+DNdyizRXt1fC0+DFHcTx60c+hJHBb5KG2wU=; b=HfjcCjspuWUh3fkCLmOCJ6dcsbvMLVwTxs90C9I4svxTngJjB08HpE6Q UMg5bokm3LsUVDM6hRvdP+Wc71so0B//BLheUY/pBQvg/lEy+4c0BijI9 8s7KmYujFbYbydzu+qQOlEkl+pasBcN/PiKN5OA3bbeCnDzn12Kt1A3jH N1NnYXl2kUlX8JO+8nGNKJNEBn8yNLDvgSM2yyZLMuCpyXvhR4lBUZCjZ J6fFLRETEVD1AuSosqfXpxTWOnit037F+4Lklzjwc6czIZqST3vLOD9Uh dpaGCKa+Oo5HveN/9OiSqtiB7HBmYnh6KgsdfGH0S87Kg3k3c7l4OPjo+ w==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="13584590" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="13584590" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:40:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="10265276" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa004.jf.intel.com with ESMTP; 22 Feb 2024 10:40:08 -0800 Subject: [RFC][PATCH 31/34] x86/cpu/intel: Mark BSP init function as __init To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:40:07 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222184007.9E437D9D@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 boot CPU is obviously not initialized during normal system runtime and its code can be __init. This prevents a warning once 'bsp_addr_config' gets marked __init. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/cpu/intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN arch/x86/kernel/cpu/intel.c~bsp_init_intel-__init arch/x86/kernel= /cpu/intel.c --- a/arch/x86/kernel/cpu/intel.c~bsp_init_intel-__init 2024-02-22 10:09:03= .721052435 -0800 +++ b/arch/x86/kernel/cpu/intel.c 2024-02-22 10:09:03.725052592 -0800 @@ -433,7 +433,7 @@ static void set_min_cache_bits(struct cp } } =20 -static void bsp_init_intel(struct cpuinfo_x86 *c) +static void __init bsp_init_intel(struct cpuinfo_x86 *c) { int keyid_bits =3D 0; =20 _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 F3CB114F97B for ; Thu, 22 Feb 2024 18:40:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627213; cv=none; b=Wj0vHpaWRvqGw7Ea9YUS3Tq+62xe44MZjKsBv3rMSzMi102/jPC4cjCLVLs6hwPmxvgssCeSM1sum1+n5yNsCm/IZMwAXFZD6cb9yr/BX9A4PoCxtM6jyghwMdYvq3LAbUI7Mu6ck0WW7zJMW0Uct/7LEULAW/0FYeDQW+/qTvI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627213; c=relaxed/simple; bh=ffiyNtjtFtp2uyQu201PfaCVjvxQzBbaXVP6y2cCQAo=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=mJAjWKXH2GhppBxmVELbpa9aXkm3vS845llsBYfDj2ByjA2b3Neqro573JBLqUuqAA1+H4SUZODzDbIQSem2r+xX27zH0xkOIBQhrNWD0qjZnfblaGbRPlxkOQOPz1Iz/n5xiJFIpVKJQmtOQWo24M2ek5s64BGD7FbGkOHrDW0= 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=AaisjB1w; arc=none smtp.client-ip=192.198.163.9 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="AaisjB1w" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627210; x=1740163210; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=ffiyNtjtFtp2uyQu201PfaCVjvxQzBbaXVP6y2cCQAo=; b=AaisjB1w+v+5IydgIMQL0TaNCEQIOpvxlTEZNGipJ4g3WmEv7bnntKAx gHMKXeN4DiAL7FtUuQAw76FDkHn7Gkqmxez7AuvdHmGGX/VxpjS6uol+c 72L5t1HAbX8hZLcNrGj4CeAPJIQN5t+iecjVd191DRYFGIxvNBaH39pnY upaIwJ+bzcZMpjs2J5amY4FUxa2bnXmnsBAEW6X9+UA4GV9F3haBxunV/ kSDsFR1gt6910xQjU3DbS9oKpHBxXZ1p67wMaxy1cD3hhD2kYxmCycn+G 17fg3PJCw104THcNG8z2Lfu7GKzJCSkUS4PcGjRaLpbFKZMkQV3WhwJau g==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="13584600" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="13584600" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:40:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="10265286" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa004.jf.intel.com with ESMTP; 22 Feb 2024 10:40:09 -0800 Subject: [RFC][PATCH 32/34] x86/cpu/amd: Move memory encryption detection To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:40:08 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222184008.9A33B01E@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 Right now the AMD memory encryption detection code is run on every CPU despite it operating on 'bsp_addr_config' and doing setup_clear_cpu_cap() which only affects 'boot_cpu_data'. Move it to bsp_init_amd() where it belongs and change its name to match. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/cpu/amd.c | 110 ++++++++++++++++++++++-----------------= ----- 1 file changed, 55 insertions(+), 55 deletions(-) diff -puN arch/x86/kernel/cpu/amd.c~early_init_amd-__init arch/x86/kernel/c= pu/amd.c --- a/arch/x86/kernel/cpu/amd.c~early_init_amd-__init 2024-02-22 10:09:04.2= 01071279 -0800 +++ b/arch/x86/kernel/cpu/amd.c 2024-02-22 10:09:04.201071279 -0800 @@ -468,8 +468,62 @@ static void early_init_amd_mc(struct cpu #endif } =20 -static void bsp_init_amd(struct cpuinfo_x86 *c) +static void bsp_detect_mem_encrypt(struct cpuinfo_x86 *c) { + u64 msr; + + /* + * BIOS support is required for SME and SEV. + * For SME: If BIOS has enabled SME then adjust x86_phys_bits by + * the SME physical address space reduction value. + * If BIOS has not enabled SME then don't advertise the + * SME feature (set in scattered.c). + * If the kernel has not enabled SME via any means then + * don't advertise the SME feature. + * For SEV: If BIOS has not enabled SEV then don't advertise the + * SEV and SEV_ES feature (set in scattered.c). + * + * In all cases, since support for SME and SEV requires long mode, + * don't advertise the feature under CONFIG_X86_32. + */ + if (cpu_has(c, X86_FEATURE_SME) || cpu_has(c, X86_FEATURE_SEV)) { + /* Check if memory encryption is enabled */ + rdmsrl(MSR_AMD64_SYSCFG, msr); + if (!(msr & MSR_AMD64_SYSCFG_MEM_ENCRYPT)) + goto clear_all; + + /* + * Always adjust physical address bits. Even though this + * will be a value above 32-bits this is still done for + * CONFIG_X86_32 so that accurate values are reported. + */ + bsp_addr_config.phys_addr_reduction_bits =3D + (cpuid_ebx(0x8000001f) >> 6) & 0x3f; + + if (IS_ENABLED(CONFIG_X86_32)) + goto clear_all; + + if (!sme_me_mask) + setup_clear_cpu_cap(X86_FEATURE_SME); + + rdmsrl(MSR_K7_HWCR, msr); + if (!(msr & MSR_K7_HWCR_SMMLOCK)) + goto clear_sev; + + return; + +clear_all: + setup_clear_cpu_cap(X86_FEATURE_SME); +clear_sev: + setup_clear_cpu_cap(X86_FEATURE_SEV); + setup_clear_cpu_cap(X86_FEATURE_SEV_ES); + } +} + +static void __init bsp_init_amd(struct cpuinfo_x86 *c) +{ + bsp_detect_mem_encrypt(c); + if (cpu_has(c, X86_FEATURE_CONSTANT_TSC)) { =20 if (c->x86 > 0x10 || @@ -593,58 +647,6 @@ warn: WARN_ONCE(1, "Family 0x%x, model: 0x%x??\n", c->x86, c->x86_model); } =20 -static void early_detect_mem_encrypt(struct cpuinfo_x86 *c) -{ - u64 msr; - - /* - * BIOS support is required for SME and SEV. - * For SME: If BIOS has enabled SME then adjust x86_phys_bits by - * the SME physical address space reduction value. - * If BIOS has not enabled SME then don't advertise the - * SME feature (set in scattered.c). - * If the kernel has not enabled SME via any means then - * don't advertise the SME feature. - * For SEV: If BIOS has not enabled SEV then don't advertise the - * SEV and SEV_ES feature (set in scattered.c). - * - * In all cases, since support for SME and SEV requires long mode, - * don't advertise the feature under CONFIG_X86_32. - */ - if (cpu_has(c, X86_FEATURE_SME) || cpu_has(c, X86_FEATURE_SEV)) { - /* Check if memory encryption is enabled */ - rdmsrl(MSR_AMD64_SYSCFG, msr); - if (!(msr & MSR_AMD64_SYSCFG_MEM_ENCRYPT)) - goto clear_all; - - /* - * Always adjust physical address bits. Even though this - * will be a value above 32-bits this is still done for - * CONFIG_X86_32 so that accurate values are reported. - */ - bsp_addr_config.phys_addr_reduction_bits =3D - (cpuid_ebx(0x8000001f) >> 6) & 0x3f; - - if (IS_ENABLED(CONFIG_X86_32)) - goto clear_all; - - if (!sme_me_mask) - setup_clear_cpu_cap(X86_FEATURE_SME); - - rdmsrl(MSR_K7_HWCR, msr); - if (!(msr & MSR_K7_HWCR_SMMLOCK)) - goto clear_sev; - - return; - -clear_all: - setup_clear_cpu_cap(X86_FEATURE_SME); -clear_sev: - setup_clear_cpu_cap(X86_FEATURE_SEV); - setup_clear_cpu_cap(X86_FEATURE_SEV_ES); - } -} - static void early_init_amd(struct cpuinfo_x86 *c) { u64 value; @@ -715,8 +717,6 @@ static void early_init_amd(struct cpuinf if (c->x86 =3D=3D 0x16 && c->x86_model <=3D 0xf) msr_set_bit(MSR_AMD64_LS_CFG, 15); =20 - early_detect_mem_encrypt(c); - /* Re-enable TopologyExtensions if switched off by BIOS */ if (c->x86 =3D=3D 0x15 && (c->x86_model >=3D 0x10 && c->x86_model <=3D 0x6f) && _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 00B1014F982 for ; Thu, 22 Feb 2024 18:40:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627215; cv=none; b=VZ8ltX3SM7EEXqfTktvOLfhoeymi+6lUmMK2Hku8mrtAyXRo7wqaqLtPTdjBLIUAGTtUGrL4xBJGs3Y5ccDIvMATCQkaGa7Um+8wjh9vrPEm5ZHXhyZpvmYpuMppP861gSdpb8qc3khMeZEy5E4OM/LBE8LrczbvVqIVtF2SwfU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627215; c=relaxed/simple; bh=Obutb+ESHGeqmvetKboeJ++LnGPxlJatRe9M06PslHw=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=gIHQ94+l4riQqWIhf2058H41ZUxIkj8iblHnhOYUW0TVtuS582a2MNbcNlHZVQOMiXw2keKuh97ywG4Ivmmn7ib0Ag4xP8rnhKTs0PezTuIooqSuTtzZOAlQ/MGzpkl64CwWo/jjI4sHQat6dTiyIwr2RmGG7tqZaNZL7CuYxhE= 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=XMmQWUkS; arc=none smtp.client-ip=192.198.163.9 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="XMmQWUkS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627212; x=1740163212; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=Obutb+ESHGeqmvetKboeJ++LnGPxlJatRe9M06PslHw=; b=XMmQWUkSPSoZY/ijTDEWeuGmpzCV/TRXR3n8mcCJMRTlsLEO8TRD6/Vu 5dFBurbEcjD36x7UdTggNcymPUyOzzaJ6FyctAxQnBhJutwZBjlVBsGgg C+j6+WF08SxcytSPc79XAyIMHvTtW/ub6ij0ekuWmDxXtORfYcXcPzAW4 BJ497F5Eguey5fw4Yo2uOsr5l1WHnkTynukjPB7SX08elVLTBKew+4DOR SeACujQ59sr8jWJbFJOdulX2xo60BIvhxWCt6qhTWNaAOf4sBfojJWfK8 Bd8Z0YFAi9AGyTtyiehltfXS0vzzbsPOmgXmLoDuu3CQvxIvPeNg3Mawd A==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="13584605" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="13584605" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:40:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="10265302" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa004.jf.intel.com with ESMTP; 22 Feb 2024 10:40:10 -0800 Subject: [RFC][PATCH 33/34] x86/cpu: Make get_cpu_address_sizes() static and __init To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:40:09 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222184009.B40837D5@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 Now that all the other users are gone and the final user is in the same file and __init, get_cpu_address_sizes() can be static and __init. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/cpu/common.c | 2 +- b/arch/x86/kernel/cpu/cpu.h | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff -puN arch/x86/kernel/cpu/common.c~get_cpu_address_sizes-__init arch/x8= 6/kernel/cpu/common.c --- a/arch/x86/kernel/cpu/common.c~get_cpu_address_sizes-__init 2024-02-22 = 10:09:04.677089966 -0800 +++ b/arch/x86/kernel/cpu/common.c 2024-02-22 10:09:04.681090123 -0800 @@ -1109,7 +1109,7 @@ void get_cpu_cap(struct cpuinfo_x86 *c) apply_forced_caps(c); } =20 -void get_cpu_address_sizes(struct cpuinfo_x86 *c) +static void __init get_cpu_address_sizes(struct cpuinfo_x86 *c) { u32 eax, ebx, ecx, edx; bool vp_bits_from_cpuid =3D true; diff -puN arch/x86/kernel/cpu/cpu.h~get_cpu_address_sizes-__init arch/x86/k= ernel/cpu/cpu.h --- a/arch/x86/kernel/cpu/cpu.h~get_cpu_address_sizes-__init 2024-02-22 10:= 09:04.677089966 -0800 +++ b/arch/x86/kernel/cpu/cpu.h 2024-02-22 10:09:04.681090123 -0800 @@ -64,7 +64,6 @@ static inline void tsx_ap_init(void) { } extern void init_spectral_chicken(struct cpuinfo_x86 *c); =20 extern void get_cpu_cap(struct cpuinfo_x86 *c); -extern void get_cpu_address_sizes(struct cpuinfo_x86 *c); extern void cpu_detect_cache_sizes(struct cpuinfo_x86 *c); extern void init_scattered_cpuid_features(struct cpuinfo_x86 *c); extern void init_intel_cacheinfo(struct cpuinfo_x86 *c); _ From nobody Fri Dec 19 20:36:45 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 1B82314EFFF for ; Thu, 22 Feb 2024 18:40:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627216; cv=none; b=S1r6khniYM1SOcyJbKsyQ/r8aJNIoXhG7UWr2IQX13alUPcl9KKKnFDj2SZMyJWl7JHhYnoJFQzObYkfNNFNghzdJdyhsodeNkA4VeokrvEKH/nB5+k40LB0MBUOOnqewRdH0AnTX4XeLmKxb1FKpDniR1Y5CFCzZ2YL+7GVj1U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708627216; c=relaxed/simple; bh=fXLqFFG0AjuZrNznR9RhW13fpkiv+9dzopyFF9ZKnd8=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=EFRdR6niaVWXJ41qfgFGnRZutbjvTZbpulnZQr28Kr5c7FdqjzichCOkeFGKY2EcKeg+j4/C1oIx6ig0DKGJYergS8KUmxggXmWgIxLbDe0VZn9iG1JVAjH/oYx0O1I1l5sriZ5Cum7TjZ8vxyRtEK/t0A/w4z2unMaa1g0vkrE= 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=PbJzUVpr; arc=none smtp.client-ip=192.198.163.9 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="PbJzUVpr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708627212; x=1740163212; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=fXLqFFG0AjuZrNznR9RhW13fpkiv+9dzopyFF9ZKnd8=; b=PbJzUVpr/JqnOoEKivrbAsqqXjDMAEMSsHe40XLy6eXIuaYAsTqMVOC8 YzSvumvh+ZuVm6pQLD9GboRJQbLdTtNHd40mMwZqli3LKE8cUIROO9wkc 4cBudFY/ayMa3xK669AOJsruGyfB2aXHV6cl0IMPxX9k20fzoXUxXsZcA UAAPoxkn76ZXF9iXZL9SwQNuVg56zEjFn8CLwzHnj6yHlmE/8LOIjpVxk xhm1vm33mFUQKoQ2bDGuxCOvg3KFVNh6E5pheDEaNYrVtj6z6hHlsZegY 5iRitYgCrB+e7nb7VN3+Usd3aHlN6FcVxcy7UC9nhyAQvlKcwsKv2eKRc g==; X-IronPort-AV: E=McAfee;i="6600,9927,10992"; a="13584610" X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="13584610" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2024 10:40:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,179,1705392000"; d="scan'208";a="10265320" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by orviesa004.jf.intel.com with ESMTP; 22 Feb 2024 10:40:12 -0800 Subject: [RFC][PATCH 34/34] x86/cpu: Mark new boot CPU and config structures appropriately To: linux-kernel@vger.kernel.org Cc: kirill.shutemov@linux.intel.com,pbonzini@redhat.com,tglx@linutronix.de,x86@kernel.org,bp@alien8.de,Dave Hansen From: Dave Hansen Date: Thu, 22 Feb 2024 10:40:11 -0800 References: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> In-Reply-To: <20240222183926.517AFCD2@davehans-spike.ostc.intel.com> Message-Id: <20240222184011.9FCCBCBD@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 Just to recap the rules: 1. 'bsp_addr_config' is only used in early boot by the BSP. 2. 'x86_config' is only written once by the BSP and can be used read-only during normal system operation Mark 'bsp_addr_config' so it goes away after boot *and* non-init references to it can be detected and warned about. Mark 'x86_config' as __ro_after_init so it does not turn into the same mess that 'boot_cpu_data' is. Signed-off-by: Dave Hansen --- b/arch/x86/kernel/setup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -puN arch/x86/kernel/setup.c~mark-new-structs arch/x86/kernel/setup.c --- a/arch/x86/kernel/setup.c~mark-new-structs 2024-02-22 10:09:05.17310943= 8 -0800 +++ b/arch/x86/kernel/setup.c 2024-02-22 10:09:05.177109595 -0800 @@ -131,8 +131,8 @@ struct ist_info ist_info; struct cpuinfo_x86 boot_cpu_data __read_mostly; EXPORT_SYMBOL(boot_cpu_data); =20 -struct x86_addr_config bsp_addr_config; -struct x86_sys_config x86_config __read_mostly; +struct x86_addr_config bsp_addr_config __initdata; +struct x86_sys_config x86_config __ro_after_init; =20 #if !defined(CONFIG_X86_PAE) || defined(CONFIG_X86_64) __visible unsigned long mmu_cr4_features __ro_after_init; _