RE: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches
Thanks, Kan -- your patch looks good, and cleaner than the previous method!
Tonight, I've tested it on our in-house simulator for the following
configurations. The simulator has been matching hardware well for this issue --
we'll do more testing on real hardware, but I'm confident you have it right.
Terminology:
"hubless" -- equivalent to "glueless" or "white box" where our BIOS sets things
up with a single bus for all sockets.
"scalable" -- BIOS assigns a new segment/domain for each socket
Configurations tested so far:
- single-socket hubless/scalable
- two sockets, scalable
- four sockets, hubless
- eight sockets, scalable
In all cases, skx_count_chabox() is returning 28 for Skylake server.
Thanks for the quick response!
Gary
> -Original Message-
> From: Liang, Kan [mailto:kan.li...@linux.intel.com]
> Sent: Monday, March 12, 2018 8:43 PM
> To: Kroening, Gary; mi...@redhat.com; h...@zytor.com; t...@linutronix.de;
> pet...@infradead.org
> Cc: Travis, Mike; Banman, Andrew; Sivanich, Dimitri; Anderson, Russ;
> x...@kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-
> segment arches
>
>
>
> On 3/7/2018 3:33 PM, Kroening, Gary wrote:
> > For systems with a single PCI segment, it is sufficient to look for the
> > bus number to change in order to determine that all of the CHa's have
> > been counted for a single socket.
> >
> > However, for multi PCI segment systems, each socket is given a new
> > segment and the bus number does NOT change. So looking only for the
> > bus number to change ends up counting all of the CHa's on all sockets
> > in the system. This leads to writing CPU MSRs beyond a valid range and
> > causes an error in ivbep_uncore_msr_init_box().
> >
> > The fix is to check for either the bus number or segment number to
> change.
> >
>
> Hi Gary,
>
> There is a recommended way in uncore document to query the number of
> CHAs on Skylake server.
> I have a patch to implement the new way.
>
> Could you please take a look at the patch and see if it can fix your
> issue?
>
>
> Thanks,
> Kan
>
> --
> From 55f54b2fa3021c691c2fd4f5cfc8f441fd104e91 Mon Sep 17 00:00:00 2001
> From: Kan Liang
> Date: Mon, 12 Mar 2018 13:03:40 -0700
> Subject: [PATCH] perf/x86/intel/uncore: Querying number of CHAs from
> CAPID6 register
>
> The number of CHAs is miscalculated on multi PCI domain systems on
> Skylake server
>
> (From Kroening, Gary:
>
> For systems with a single PCI segment, it is sufficient to look for the
> bus number to change in order to determine that all of the CHa's have
> been counted for a single socket.
> However, for multi PCI segment systems, each socket is given a new
> segment and the bus number does NOT change. So looking only for the
> bus number to change ends up counting all of the CHa's on all sockets
> in the system. This leads to writing CPU MSRs beyond a valid range and
> causes an error in ivbep_uncore_msr_init_box().)
>
> To determine the number of CHAs, it should read bits 27:0 in the CAPID6
> register located at Device 30, Function 3, Offset 0x9C. These 28 bits
> form a bit vector of available LLC slices and the CHAs that manage those
> slices.
>
> Fixes: cd34cd97b7b4 ("perf/x86/intel/uncore: Add Skylake server uncore
> support")
> Reported-by: Kroening, Gary
> Signed-off-by: Kan Liang
> ---
> arch/x86/events/intel/uncore_snbep.c | 24 ++--
> 1 file changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/arch/x86/events/intel/uncore_snbep.c
> b/arch/x86/events/intel/uncore_snbep.c
> index d4672ed..a42715b 100644
> --- a/arch/x86/events/intel/uncore_snbep.c
> +++ b/arch/x86/events/intel/uncore_snbep.c
> @@ -3575,24 +3575,20 @@ static struct intel_uncore_type
> *skx_msr_uncores[] = {
> NULL,
> };
>
> +#define SKX_CAPID6 0x9c
> +#define SKX_CHA_BIT_WIDTH28
> +
> static int skx_count_chabox(void)
> {
> - struct pci_dev *chabox_dev = NULL;
> - int bus, count = 0;
> + struct pci_dev *dev = NULL;
> + u32 val = 0;
>
> - while (1) {
> - chabox_dev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x208d,
> chabox_dev);
> - if (!chabox_dev)
> - break;
> - if (count == 0)
> - bus = chabox_dev->bus->number;
> - if (bus != chabox_dev->bus->number)
> - break;
> - count++;
> - }
> + dev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x2083, dev);
> + if (!dev)
> + return 0;
>
> - pci_dev_put(chabox_dev);
> - return count;
> + pci_read_config_dword(dev, SKX_CAPID6, &val);
> + return bitmap_weight((unsigned long *)&val, SKX_CHA_BIT_WIDTH);
> }
>
> void skx_uncore_cpu_init(void)
> --
> 2.7.4
RE: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches
Kan -- sorry for my late-night typo. My description for "hubless" should have
said "a single segment/domain" rather than single bus.
> "hubless" -- equivalent to "glueless" or "white box" where our BIOS sets
> things up with a single bus for all sockets.
single segment/domain *
Sorry for the spam!
Gary
> -Original Message-
> From: Kroening, Gary
> Sent: Tuesday, March 13, 2018 12:07 AM
> To: 'Liang, Kan'; mi...@redhat.com; h...@zytor.com; t...@linutronix.de;
> pet...@infradead.org
> Cc: Travis, Mike; Banman, Andrew; Sivanich, Dimitri; Anderson, Russ;
> x...@kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-
> segment arches
>
> Thanks, Kan -- your patch looks good, and cleaner than the previous
> method!
>
> Tonight, I've tested it on our in-house simulator for the following
> configurations. The simulator has been matching hardware well for this
> issue -- we'll do more testing on real hardware, but I'm confident you
> have it right.
>
> Terminology:
>
> "hubless" -- equivalent to "glueless" or "white box" where our BIOS sets
> things up with a single bus for all sockets.
>
> "scalable" -- BIOS assigns a new segment/domain for each socket
>
> Configurations tested so far:
> - single-socket hubless/scalable
> - two sockets, scalable
> - four sockets, hubless
> - eight sockets, scalable
>
> In all cases, skx_count_chabox() is returning 28 for Skylake server.
> Thanks for the quick response!
> Gary
>
> > -Original Message-
> > From: Liang, Kan [mailto:kan.li...@linux.intel.com]
> > Sent: Monday, March 12, 2018 8:43 PM
> > To: Kroening, Gary; mi...@redhat.com; h...@zytor.com; t...@linutronix.de;
> > pet...@infradead.org
> > Cc: Travis, Mike; Banman, Andrew; Sivanich, Dimitri; Anderson, Russ;
> > x...@kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-
> pci-
> > segment arches
> >
> >
> >
> > On 3/7/2018 3:33 PM, Kroening, Gary wrote:
> > > For systems with a single PCI segment, it is sufficient to look for
> the
> > > bus number to change in order to determine that all of the CHa's have
> > > been counted for a single socket.
> > >
> > > However, for multi PCI segment systems, each socket is given a new
> > > segment and the bus number does NOT change. So looking only for the
> > > bus number to change ends up counting all of the CHa's on all sockets
> > > in the system. This leads to writing CPU MSRs beyond a valid range
> and
> > > causes an error in ivbep_uncore_msr_init_box().
> > >
> > > The fix is to check for either the bus number or segment number to
> > change.
> > >
> >
> > Hi Gary,
> >
> > There is a recommended way in uncore document to query the number of
> > CHAs on Skylake server.
> > I have a patch to implement the new way.
> >
> > Could you please take a look at the patch and see if it can fix your
> > issue?
> >
> >
> > Thanks,
> > Kan
> >
> > --
> > From 55f54b2fa3021c691c2fd4f5cfc8f441fd104e91 Mon Sep 17 00:00:00 2001
> > From: Kan Liang
> > Date: Mon, 12 Mar 2018 13:03:40 -0700
> > Subject: [PATCH] perf/x86/intel/uncore: Querying number of CHAs from
> > CAPID6 register
> >
> > The number of CHAs is miscalculated on multi PCI domain systems on
> > Skylake server
> >
> > (From Kroening, Gary:
> >
> > For systems with a single PCI segment, it is sufficient to look for the
> > bus number to change in order to determine that all of the CHa's have
> > been counted for a single socket.
> > However, for multi PCI segment systems, each socket is given a new
> > segment and the bus number does NOT change. So looking only for the
> > bus number to change ends up counting all of the CHa's on all sockets
> > in the system. This leads to writing CPU MSRs beyond a valid range and
> > causes an error in ivbep_uncore_msr_init_box().)
> >
> > To determine the number of CHAs, it should read bits 27:0 in the CAPID6
> > register located at Device 30, Function 3, Offset 0x9C. These 28 bits
> > form a bit vector of available LLC slices and the CHAs that manage those
> > slices.
> >
> > Fixes: cd34cd97b7b4 ("perf/x86/intel/uncore: Add Skylake server uncore
> > support")
> > Reported-by: Kroening, Gary
> > Signed-of
[PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches
For systems with a single PCI segment, it is sufficient to look for the
bus number to change in order to determine that all of the CHa's have
been counted for a single socket.
However, for multi PCI segment systems, each socket is given a new
segment and the bus number does NOT change. So looking only for the
bus number to change ends up counting all of the CHa's on all sockets
in the system. This leads to writing CPU MSRs beyond a valid range and
causes an error in ivbep_uncore_msr_init_box().
The fix is to check for either the bus number or segment number to change.
Signed-off-by: Gary Kroening
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
---
arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- linux-4.4.orig/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c
+++ linux-4.4/arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c
@@ -3525,15 +3525,19 @@ static struct intel_uncore_type *skx_msr
static int skx_count_chabox(void)
{
struct pci_dev *chabox_dev = NULL;
- int bus, count = 0;
+ int bus, seg, count = 0;
while (1) {
chabox_dev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x208d,
chabox_dev);
if (!chabox_dev)
break;
- if (count == 0)
+ if (count == 0) {
bus = chabox_dev->bus->number;
- if (bus != chabox_dev->bus->number)
+ seg = pci_domain_nr(chabox_dev->bus);
+ }
+ /* check for change in both bus and domain/segment */
+ if (bus != chabox_dev->bus->number ||
+ seg != pci_domain_nr(chabox_dev->bus))
break;
count++;
}
RE: [PATCH V2] perf/x86/intel/uncore: Querying number of CHAs from CAPID6 register
I've tested this patch on the same set of hubless (single-segment) and scalable
(segment-per-socket) configurations as for Kan's version 1.
As far as we can tell this will also work for Cascade Lake, but will need
revisiting for Ice Lake.
Thanks.
Gary
> -Original Message-
> From: kan.li...@linux.intel.com [mailto:kan.li...@linux.intel.com]
> Sent: Tuesday, March 13, 2018 1:52 PM
> To: mi...@redhat.com; h...@zytor.com; t...@linutronix.de;
> pet...@infradead.org; andy.shevche...@gmail.com
> Cc: Kroening, Gary; Travis, Mike; Banman, Andrew; Sivanich, Dimitri;
> Anderson, Russ; x...@kernel.org; linux-kernel@vger.kernel.org; Kan Liang
> Subject: [PATCH V2] perf/x86/intel/uncore: Querying number of CHAs from
> CAPID6 register
>
> From: Kan Liang
>
> The number of CHAs is miscalculated on multi PCI domain systems on
> Skylake server.
>
> (From Kroening, Gary:
>
> For systems with a single PCI segment, it is sufficient to look for the
> bus number to change in order to determine that all of the CHa's have
> been counted for a single socket.
> However, for multi PCI segment systems, each socket is given a new
> segment and the bus number does NOT change. So looking only for the
> bus number to change ends up counting all of the CHa's on all sockets
> in the system. This leads to writing CPU MSRs beyond a valid range and
> causes an error in ivbep_uncore_msr_init_box().)
>
> To determine the number of CHAs, it should read bits 27:0 in the CAPID6
> register located at Device 30, Function 3, Offset 0x9C. These 28 bits
> form a bit vector of available LLC slices and the CHAs that manage those
> slices.
>
> Fixes: cd34cd97b7b4 ("perf/x86/intel/uncore: Add Skylake server uncore
> support")
> Reported-by: Kroening, Gary
> Signed-off-by: Kan Liang
> ---
>
> Changes since V1:
> - add missed pci_dev_put()
> - Drop ugly casting by using hweight32()
> - Add comments for macros.
>
> arch/x86/events/intel/uncore_snbep.c | 31 +--
> 1 file changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/arch/x86/events/intel/uncore_snbep.c
> b/arch/x86/events/intel/uncore_snbep.c
> index 6d8044a..8970f71 100644
> --- a/arch/x86/events/intel/uncore_snbep.c
> +++ b/arch/x86/events/intel/uncore_snbep.c
> @@ -3562,24 +3562,27 @@ static struct intel_uncore_type *skx_msr_uncores[]
> = {
> NULL,
> };
>
> +/*
> + * To determine the number of CHAs, it should read bits 27:0 in the
> CAPID6
> + * register which located at Device 30, Function 3, Offset 0x9C. PCI ID
> 0x2083.
> + */
> +#define SKX_CAPID6 0x9c
> +#define SKX_CHA_BIT_MASK GENMASK(27, 0)
> +
> static int skx_count_chabox(void)
> {
> - struct pci_dev *chabox_dev = NULL;
> - int bus, count = 0;
> + struct pci_dev *dev = NULL;
> + u32 val = 0;
>
> - while (1) {
> - chabox_dev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x208d,
> chabox_dev);
> - if (!chabox_dev)
> - break;
> - if (count == 0)
> - bus = chabox_dev->bus->number;
> - if (bus != chabox_dev->bus->number)
> - break;
> - count++;
> - }
> + dev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x2083, dev);
> + if (!dev)
> + goto out;
>
> - pci_dev_put(chabox_dev);
> - return count;
> + pci_read_config_dword(dev, SKX_CAPID6, &val);
> + val &= SKX_CHA_BIT_MASK;
> +out:
> + pci_dev_put(dev);
> + return hweight32(val);
> }
>
> void skx_uncore_cpu_init(void)
> --
> 2.7.4
