All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Charles (Chas) Williams" <ciwillia@brocade.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	<x86@kernel.org>, <linux-kernel@vger.kernel.org>,
	"M. Vefa Bicakci" <m.v.b@runbox.com>
Subject: Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory
Date: Tue, 8 Nov 2016 09:57:19 -0500	[thread overview]
Message-ID: <86609338-2b45-ed7e-fb07-99421e43a2f1@brocade.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1611081525160.3501@nanos>



On 11/08/2016 09:31 AM, Thomas Gleixner wrote:
> On Tue, 8 Nov 2016, Charles (Chas) Williams wrote:
>> 	[    0.016335] topology_update_package_map:  apicid 0  pkg 0  cpu 0
>> 	[    0.016398] smpboot: APIC(0) Converting physical 0 to logical
>> package 0, cpu 0 (ffff88023fc0a040)
>> 	[    0.016399] topology_update_package_map:  apicid 1  pkg 1  cpu 1
>> 	[    0.016462] smpboot: APIC(1) Converting physical 1 to logical
>> package 1, cpu 1 (ffff88023fd0a040)
>>
>> So, I don't know where apic->cpu_present_to_apicid(cpu) is getting its
>> apicid but it certainly doesn't seem to the match the apicid in the
>> CPU's registers.  For whatever reason, my VMware system is reporting
>> that the second CPU has a local APIC ID of 2:
>
> The initial information comes from MP tables or ACPI.
>
>> 	[    0.009115] identify_cpu: cpu_index 0  phys_proc_id is now 0,
>> apicid 0, initial_apicid 0
>> 	...
>> 	[    0.237401] identify_cpu: cpu_index 1  phys_proc_id is now 2,
>> apicid 2, initial_apicid 2
>
> And the CPUID emulation tells something different. Sigh!
>
>> I was thinking it might be better to call topology_update_package_map()
>> at the bottom of identify_cpu() to setup the secondary CPU's.  The boot
>> cpu could be setup during smp_init_package_map().
>
> Perhaps, but that does not make the inconsistencies go away....

By the time I know it's not consistent, there isn't anything I can do
about it.  I can't update the table to remove the bad information.

The other alternative, is to trust the ACPI and just update the
cpu_data's apicid in identify_cpu() to the value from the table.
The earlier kernels didn't seem to rely as much on this information.
But it does appear to be "wrong" in the APIC table.  From acpidump:

[02Ch 0044   1]                Subtable Type : 00 [Processor Local APIC]
[02Dh 0045   1]                       Length : 08
[02Eh 0046   1]                 Processor ID : 00
[02Fh 0047   1]                Local Apic ID : 00
[030h 0048   4]        Flags (decoded below) : 00000001
                            Processor Enabled : 1

[034h 0052   1]                Subtable Type : 00 [Processor Local APIC]
[035h 0053   1]                       Length : 08
[036h 0054   1]                 Processor ID : 01
[037h 0055   1]                Local Apic ID : 01
[038h 0056   4]        Flags (decoded below) : 00000001
                            Processor Enabled : 1

  reply	other threads:[~2016-11-08 14:57 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-02 12:25 [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory Sebastian Andrzej Siewior
2016-11-02 22:47 ` Charles (Chas) Williams
2016-11-03 17:47   ` Sebastian Andrzej Siewior
2016-11-04 12:20     ` Charles (Chas) Williams
2016-11-04 18:03       ` Sebastian Andrzej Siewior
2016-11-04 20:42         ` Charles (Chas) Williams
2016-11-04 20:57           ` Sebastian Andrzej Siewior
2016-11-07 16:19   ` Thomas Gleixner
2016-11-07 16:59     ` Charles (Chas) Williams
2016-11-07 20:20       ` Thomas Gleixner
2016-11-08 14:20         ` Charles (Chas) Williams
2016-11-08 14:31           ` Thomas Gleixner
2016-11-08 14:57             ` Charles (Chas) Williams [this message]
2016-11-08 16:22               ` Thomas Gleixner
2016-11-09 15:35                 ` [PATCH] x86/cpuid: Deal with broken firmware once more Thomas Gleixner
2016-11-09 15:37                   ` Thomas Gleixner
2016-11-09 16:03                   ` Peter Zijlstra
2016-11-09 16:34                     ` Charles (Chas) Williams
2016-11-09 18:37                       ` Thomas Gleixner
2016-11-09 18:15                   ` Charles (Chas) Williams
2016-11-09 20:27                   ` [tip:x86/urgent] x86/cpu: Deal with broken firmware (VMWare/XEN) tip-bot for Thomas Gleixner
2016-11-11  5:49                     ` Alok Kataria
2016-11-10  3:57                   ` [PATCH] x86/cpuid: Deal with broken firmware once more M. Vefa Bicakci
2016-11-10 10:50                     ` Charles (Chas) Williams
2016-11-10 11:14                       ` Thomas Gleixner
2016-11-12 22:05                       ` M. Vefa Bicakci
2016-11-10 11:13                     ` Thomas Gleixner
2016-11-10 11:39                       ` Peter Zijlstra
2016-11-10 14:02                       ` Boris Ostrovsky
2016-11-10 15:05                         ` Charles (Chas) Williams
2016-11-10 15:31                           ` Boris Ostrovsky
2016-11-10 15:54                             ` Sebastian Andrzej Siewior
2016-11-10 17:15                             ` Thomas Gleixner
2016-11-12 22:05                             ` M. Vefa Bicakci
2016-11-13 18:04                               ` Boris Ostrovsky
2016-11-13 23:42                                 ` M. Vefa Bicakci
2016-11-13 23:42                                 ` M. Vefa Bicakci
2016-11-15  1:21                                   ` Boris Ostrovsky
2016-11-18 11:16                                     ` Thomas Gleixner
2016-11-18 11:16                                     ` Thomas Gleixner
2016-11-18 14:22                                       ` Boris Ostrovsky
2016-11-18 14:22                                       ` Boris Ostrovsky
2016-11-15  1:21                                   ` Boris Ostrovsky
2016-11-13 18:04                               ` Boris Ostrovsky
2016-11-10 15:12                         ` Thomas Gleixner
2016-11-10 15:38                           ` Boris Ostrovsky
2016-11-10 17:13                             ` Thomas Gleixner
2016-11-10 17:13                             ` Thomas Gleixner
2016-11-10 18:01                               ` Boris Ostrovsky
2016-11-10 18:01                                 ` Boris Ostrovsky
2016-11-10 15:38                           ` Boris Ostrovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86609338-2b45-ed7e-fb07-99421e43a2f1@brocade.com \
    --to=ciwillia@brocade.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.v.b@runbox.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.