On Mon, Jul 24, 2017 at 04:44:45PM +0200, Borislav Petkov wrote:
> On Mon, Jul 24, 2017 at 09:14:18PM +0700, Suravee Suthikulpanit wrote:
> > Actually, this is not totally accurate. My apology. This patch is
> > mainly fix to incorrect core ID in /proc/cpuinfo.
>
> So you're "fixing" only some
On Mon, Jul 24, 2017 at 04:44:45PM +0200, Borislav Petkov wrote:
> On Mon, Jul 24, 2017 at 09:14:18PM +0700, Suravee Suthikulpanit wrote:
> > Actually, this is not totally accurate. My apology. This patch is
> > mainly fix to incorrect core ID in /proc/cpuinfo.
>
> So you're "fixing" only some
On Tue, Jul 25, 2017 at 01:02:49PM +0700, Suravee Suthikulpanit wrote:
> Actually, this commit change how we derive the cpu_core_id fro family17h to
> use CPUID_Fn801E_EBX instead of from APIC ID for family17h and later.
Is the CPUID info correct also for downcored, MCM configurations? If so,
On Tue, Jul 25, 2017 at 01:02:49PM +0700, Suravee Suthikulpanit wrote:
> Actually, this commit change how we derive the cpu_core_id fro family17h to
> use CPUID_Fn801E_EBX instead of from APIC ID for family17h and later.
Is the CPUID info correct also for downcored, MCM configurations? If so,
Boris,
On 7/25/17 12:56, Borislav Petkov wrote:
On Tue, Jul 25, 2017 at 12:51:53PM +0700, Suravee Suthikulpanit wrote:
Ok. Sure, it doesn't need be contiguous. But at least the cpu_core_id should
represent an ID that make some sense since it is used in the
arch/x86/kernel/smpboot.c:
Boris,
On 7/25/17 12:56, Borislav Petkov wrote:
On Tue, Jul 25, 2017 at 12:51:53PM +0700, Suravee Suthikulpanit wrote:
Ok. Sure, it doesn't need be contiguous. But at least the cpu_core_id should
represent an ID that make some sense since it is used in the
arch/x86/kernel/smpboot.c:
On Tue, Jul 25, 2017 at 12:51:53PM +0700, Suravee Suthikulpanit wrote:
> Ok. Sure, it doesn't need be contiguous. But at least the cpu_core_id should
> represent an ID that make some sense since it is used in the
> arch/x86/kernel/smpboot.c: match_smt() and some other places. So, if it's
> invalid
On Tue, Jul 25, 2017 at 12:51:53PM +0700, Suravee Suthikulpanit wrote:
> Ok. Sure, it doesn't need be contiguous. But at least the cpu_core_id should
> represent an ID that make some sense since it is used in the
> arch/x86/kernel/smpboot.c: match_smt() and some other places. So, if it's
> invalid
Boris,
On 7/24/17 21:44, Borislav Petkov wrote:
On Mon, Jul 24, 2017 at 09:14:18PM +0700, Suravee Suthikulpanit wrote:
Actually, this is not totally accurate. My apology. This patch is
mainly fix to incorrect core ID in /proc/cpuinfo.
So you're "fixing" only some numbering thing. Because
Boris,
On 7/24/17 21:44, Borislav Petkov wrote:
On Mon, Jul 24, 2017 at 09:14:18PM +0700, Suravee Suthikulpanit wrote:
Actually, this is not totally accurate. My apology. This patch is
mainly fix to incorrect core ID in /proc/cpuinfo.
So you're "fixing" only some numbering thing. Because
On Mon, Jul 24, 2017 at 09:14:18PM +0700, Suravee Suthikulpanit wrote:
> Actually, this is not totally accurate. My apology. This patch is
> mainly fix to incorrect core ID in /proc/cpuinfo.
So you're "fixing" only some numbering thing. Because core_id doesn't
have any influence on anything.
On Mon, Jul 24, 2017 at 09:14:18PM +0700, Suravee Suthikulpanit wrote:
> Actually, this is not totally accurate. My apology. This patch is
> mainly fix to incorrect core ID in /proc/cpuinfo.
So you're "fixing" only some numbering thing. Because core_id doesn't
have any influence on anything.
Boris,
On 7/24/17 18:14, Borislav Petkov wrote:
On Mon, Jul 24, 2017 at 04:22:45AM -0500, Suravee Suthikulpanit wrote:
For family17h, current cpu_core_id is directly taken from the value
CPUID_Fn801E_EBX[7:0] (CoreId), which is the physical ID of the
core within a die. However, on system
Boris,
On 7/24/17 18:14, Borislav Petkov wrote:
On Mon, Jul 24, 2017 at 04:22:45AM -0500, Suravee Suthikulpanit wrote:
For family17h, current cpu_core_id is directly taken from the value
CPUID_Fn801E_EBX[7:0] (CoreId), which is the physical ID of the
core within a die. However, on system
On Mon, Jul 24, 2017 at 04:22:45AM -0500, Suravee Suthikulpanit wrote:
> For family17h, current cpu_core_id is directly taken from the value
> CPUID_Fn801E_EBX[7:0] (CoreId), which is the physical ID of the
> core within a die. However, on system with downcore configuration
> (where not all
On Mon, Jul 24, 2017 at 04:22:45AM -0500, Suravee Suthikulpanit wrote:
> For family17h, current cpu_core_id is directly taken from the value
> CPUID_Fn801E_EBX[7:0] (CoreId), which is the physical ID of the
> core within a die. However, on system with downcore configuration
> (where not all
For family17h, current cpu_core_id is directly taken from the value
CPUID_Fn801E_EBX[7:0] (CoreId), which is the physical ID of the
core within a die. However, on system with downcore configuration
(where not all physical cores within a die are available), this could
result in the case where
For family17h, current cpu_core_id is directly taken from the value
CPUID_Fn801E_EBX[7:0] (CoreId), which is the physical ID of the
core within a die. However, on system with downcore configuration
(where not all physical cores within a die are available), this could
result in the case where
18 matches
Mail list logo
