[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aee9764b0fbe9e37e1e7692194d9ca6f86a9db77.camel@intel.com>
Date: Tue, 27 Feb 2024 11:05:29 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
CC: "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"tglx@...utronix.de" <tglx@...utronix.de>, "pbonzini@...hat.com"
<pbonzini@...hat.com>, "rafael@...nel.org" <rafael@...nel.org>,
"lenb@...nel.org" <lenb@...nel.org>, "x86@...nel.org" <x86@...nel.org>,
"bp@...en8.de" <bp@...en8.de>
Subject: Re: [RFC][PATCH 04/34] x86/mm: Introduce physical address limit
helper
On Thu, 2024-02-22 at 10:39 -0800, Dave Hansen wrote:
> From: Dave Hansen <dave.hansen@...ux.intel.com>
>
> 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 <dave.hansen@...ux.intel.com>
> Cc: "Rafael J. Wysocki" <rafael@...nel.org>
> Cc: Len Brown <lenb@...nel.org>
> ---
>
Reviewed-by: Kai Huang <kai.huang@...el.com>
Powered by blists - more mailing lists