[PATCH] x86_64: make amd quad core 8 socket system not be clustered_box - Kernel

This is a discussion on [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box - Kernel ; quad core 8 socket system will have apic id lifting.the apic id range could be [4, 0x23]. or [8, 0x27]. apic_is_clustered_box will think that need to three clusters and that is large than 2. So it is treated as clustered_box. ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 48

Thread: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box

  1. [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box


    quad core 8 socket system will have apic id lifting.the apic id range could
    be [4, 0x23]. or [8, 0x27]. apic_is_clustered_box will think that need to three clusters
    and that is large than 2. So it is treated as clustered_box.

    and will get

    Marking TSC unstable due to TSCs unsynchronized

    even the CPUs have X86_FEATURE_CONSTANT_TSC set.

    this patch offset back the apic before get apic clusterid.

    or use dmi to get apic_is_clustered?

    Signed-off-by: Yinghai Lu

    diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
    index 9b2be3d..5bdf1bc 100644
    --- a/arch/x86/kernel/apic_64.c
    +++ b/arch/x86/kernel/apic_64.c
    @@ -1223,8 +1223,11 @@ __cpuinit int apic_is_clustered_box(void)
    else
    break;

    - if (id != BAD_APICID)
    + if (id != BAD_APICID) {
    + if (id >= boot_cpu_id)
    + id -= boot_cpu_id;
    __set_bit(APIC_CLUSTERID(id), clustermap);
    + }
    }

    /* Problem: Partially populated chassis may not have CPUs in some of
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box

    Yinghai Lu writes:

    > quad core 8 socket system will have apic id lifting.the apic id range could
    > be [4, 0x23]. or [8, 0x27]. apic_is_clustered_box will think that need to three clusters
    > and that is large than 2. So it is treated as clustered_box.
    >
    > and will get
    >
    > Marking TSC unstable due to TSCs unsynchronized
    >
    > even the CPUs have X86_FEATURE_CONSTANT_TSC set.
    >
    > this patch offset back the apic before get apic clusterid.
    >
    > or use dmi to get apic_is_clustered?


    The clustered check is for Summit and es7000 systems
    On 64bit systems it might be actually possible to trigger
    this based on SLIT instead. But you'll need to check with
    the IBM Summit/Unisys es7000 developers if that works or not

    If you don't want to do that the safer way would be probably
    the check if there are holes between the CPUs APIC numbers.
    If yes then it's likely clustered mode. I think that would
    be better than to disable it unconditionally for apic lifting
    like your patches does.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box

    On Friday 22 February 2008 11:02:30 am Yinghai Lu wrote:
    > On Friday 22 February 2008 04:25:18 am Andi Kleen wrote:
    > > Yinghai Lu writes:
    > >
    > > > quad core 8 socket system will have apic id lifting.the apic id range could
    > > > be [4, 0x23]. or [8, 0x27]. apic_is_clustered_box will think that need to three clusters
    > > > and that is large than 2. So it is treated as clustered_box.
    > > >
    > > > and will get
    > > >
    > > > Marking TSC unstable due to TSCs unsynchronized
    > > >
    > > > even the CPUs have X86_FEATURE_CONSTANT_TSC set.
    > > >
    > > > this patch offset back the apic before get apic clusterid.
    > > >
    > > > or use dmi to get apic_is_clustered?

    > >
    > > The clustered check is for Summit and es7000 systems
    > > On 64bit systems it might be actually possible to trigger
    > > this based on SLIT instead. But you'll need to check with
    > > the IBM Summit/Unisys es7000 developers if that works or not
    > >
    > > If you don't want to do that the safer way would be probably
    > > the check if there are holes between the CPUs APIC numbers.
    > > If yes then it's likely clustered mode. I think that would
    > > be better than to disable it unconditionally for apic lifting
    > > like your patches does.

    >
    > so for that box [4, 0x23] still could be apic clustered? there is a hole [0,3]..
    >
    > is their box using AMD cpu or not?


    or move
    CPUs have X86_FEATURE_CONSTANT_TSC check before apic_clustered check?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box

    On Friday 22 February 2008 04:25:18 am Andi Kleen wrote:
    > Yinghai Lu writes:
    >
    > > quad core 8 socket system will have apic id lifting.the apic id range could
    > > be [4, 0x23]. or [8, 0x27]. apic_is_clustered_box will think that need to three clusters
    > > and that is large than 2. So it is treated as clustered_box.
    > >
    > > and will get
    > >
    > > Marking TSC unstable due to TSCs unsynchronized
    > >
    > > even the CPUs have X86_FEATURE_CONSTANT_TSC set.
    > >
    > > this patch offset back the apic before get apic clusterid.
    > >
    > > or use dmi to get apic_is_clustered?

    >
    > The clustered check is for Summit and es7000 systems
    > On 64bit systems it might be actually possible to trigger
    > this based on SLIT instead. But you'll need to check with
    > the IBM Summit/Unisys es7000 developers if that works or not
    >
    > If you don't want to do that the safer way would be probably
    > the check if there are holes between the CPUs APIC numbers.
    > If yes then it's likely clustered mode. I think that would
    > be better than to disable it unconditionally for apic lifting
    > like your patches does.


    so for that box [4, 0x23] still could be apic clustered? there is a hole [0,3]..

    is their box using AMD cpu or not?

    YH

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box


    > or move
    > CPUs have X86_FEATURE_CONSTANT_TSC check before apic_clustered check?


    No that would be not correct on Intel boxes.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box

    On Fri, Feb 22, 2008 at 11:00 AM, Andi Kleen wrote:
    >
    > > so for that box [4, 0x23] still could be apic clustered? there is a hole [0,3]..

    >
    > I meant holes between the CPUs only, not including the IO-APICs.
    >
    >
    > > is their box using AMD cpu or not?

    >
    > Intel. AMD boxes don't really need clustered mode because they support
    > bigflat mode.


    So DMI or exclude AMD CPU?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box

    On Fri, Feb 22, 2008 at 11:07 AM, Andi Kleen wrote:
    >
    > Yinghai Lu wrote:
    > > On Fri, Feb 22, 2008 at 11:00 AM, Andi Kleen wrote:
    > >> > so for that box [4, 0x23] still could be apic clustered? there is a hole [0,3]..
    > >>
    > >> I meant holes between the CPUs only, not including the IO-APICs.
    > >>
    > >>
    > >> > is their box using AMD cpu or not?
    > >>
    > >> Intel. AMD boxes don't really need clustered mode because they support
    > >> bigflat mode.

    > >
    > > So DMI or exclude AMD CPU?

    >
    > Just check for holes between the cpus as I suggested earlier


    how about their system that is not full populated with CPU?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box

    Yinghai Lu wrote:
    > On Fri, Feb 22, 2008 at 11:07 AM, Andi Kleen wrote:
    >> Yinghai Lu wrote:
    >> > On Fri, Feb 22, 2008 at 11:00 AM, Andi Kleen wrote:
    >> >> > so for that box [4, 0x23] still could be apic clustered? there is a hole [0,3]..
    >> >>
    >> >> I meant holes between the CPUs only, not including the IO-APICs.
    >> >>
    >> >>
    >> >> > is their box using AMD cpu or not?
    >> >>
    >> >> Intel. AMD boxes don't really need clustered mode because they support
    >> >> bigflat mode.
    >> >
    >> > So DMI or exclude AMD CPU?

    >>
    >> Just check for holes between the cpus as I suggested earlier

    >
    > how about their system that is not full populated with CPU?


    I would expect the APIC IDs to be continuous then.

    -Andi

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box

    Yinghai Lu wrote:
    > On Fri, Feb 22, 2008 at 11:00 AM, Andi Kleen wrote:
    >> > so for that box [4, 0x23] still could be apic clustered? there is a hole [0,3]..

    >>
    >> I meant holes between the CPUs only, not including the IO-APICs.
    >>
    >>
    >> > is their box using AMD cpu or not?

    >>
    >> Intel. AMD boxes don't really need clustered mode because they support
    >> bigflat mode.

    >
    > So DMI or exclude AMD CPU?


    Just check for holes between the cpus as I suggested earlier

    -Andi

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box


    > so for that box [4, 0x23] still could be apic clustered? there is a hole [0,3]..


    I meant holes between the CPUs only, not including the IO-APICs.

    > is their box using AMD cpu or not?


    Intel. AMD boxes don't really need clustered mode because they support
    bigflat mode.

    -Andi

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box

    On Fri, Feb 22, 2008 at 11:10 AM, Andi Kleen wrote:
    > Yinghai Lu wrote:
    > > On Fri, Feb 22, 2008 at 11:07 AM, Andi Kleen wrote:
    > >> Yinghai Lu wrote:
    > >> > On Fri, Feb 22, 2008 at 11:00 AM, Andi Kleen wrote:
    > >> >> > so for that box [4, 0x23] still could be apic clustered? there is a hole [0,3]..
    > >> >>
    > >> >> I meant holes between the CPUs only, not including the IO-APICs.
    > >> >>
    > >> >>
    > >> >> > is their box using AMD cpu or not?
    > >> >>
    > >> >> Intel. AMD boxes don't really need clustered mode because they support
    > >> >> bigflat mode.
    > >> >
    > >> > So DMI or exclude AMD CPU?
    > >>
    > >> Just check for holes between the cpus as I suggested earlier

    > >
    > > how about their system that is not full populated with CPU?

    >
    > I would expect the APIC IDs to be continuous then.
    >

    so those box will have apic id hole even they are fully poluated with cpu...?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2


    quad core 8 socket system will have apic id lifting.the apic id range could
    be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
    and that is large than 2. So it is treated as clustered_box.

    and will get

    Marking TSC unstable due to TSCs unsynchronized

    even the CPUs have X86_FEATURE_CONSTANT_TSC set.

    this patch will check if the cpu is from AMD.

    Signed-off-by: Yinghai Lu

    diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
    index d8d03e0..7d8ffda 100644
    --- a/arch/x86/kernel/apic_64.c
    +++ b/arch/x86/kernel/apic_64.c
    @@ -1180,9 +1180,19 @@ __cpuinit int apic_is_clustered_box(void)
    {
    int i, clusters, zeros;
    unsigned id;
    - u16 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
    + u16 *bios_cpu_apicid;
    DECLARE_BITMAP(clustermap, NUM_APIC_CLUSTERS);

    + /*
    + * there is not this kind of box with AMD CPU yet.
    + * Some AMD box with quadcore cpu and 8 sockets apicid
    + * will be [4, 0x23] or [8, 0x27] could be thought to
    + * have three apic_clusters. So go out early.
    + */
    + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
    + return 0;
    +
    + bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
    bitmap_zero(clustermap, NUM_APIC_CLUSTERS);

    for (i = 0; i < NR_CPUS; i++) {
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2


    * Yinghai Lu wrote:

    > quad core 8 socket system will have apic id lifting.the apic id range
    > could be [4, 0x23]. and apic_is_clustered_box will think that need to
    > three clusters and that is large than 2. So it is treated as
    > clustered_box.
    >
    > and will get
    >
    > Marking TSC unstable due to TSCs unsynchronized
    >
    > even the CPUs have X86_FEATURE_CONSTANT_TSC set.
    >
    > this patch will check if the cpu is from AMD.


    thanks Yinghai, applied.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2

    On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote:
    >
    > quad core 8 socket system will have apic id lifting.the apic id range could
    > be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
    > and that is large than 2. So it is treated as clustered_box.


    Ok I see you chose the quick hack over doing it properly ...

    >
    > and will get
    >
    > Marking TSC unstable due to TSCs unsynchronized
    >
    > even the CPUs have X86_FEATURE_CONSTANT_TSC set.


    I doubt that will do the right thing on AMD based vSMP,
    which also required the cluster check on AMD iirc.

    Cc'ed Kiran/Shai. damage has already hit x86 tree I believe.

    -Andi

    diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
    index d8d03e0..7d8ffda 100644
    --- a/arch/x86/kernel/apic_64.c
    +++ b/arch/x86/kernel/apic_64.c
    @@ -1180,9 +1180,19 @@ __cpuinit int apic_is_clustered_box(void)
    {
    int i, clusters, zeros;
    unsigned id;
    - u16 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
    + u16 *bios_cpu_apicid;
    DECLARE_BITMAP(clustermap, NUM_APIC_CLUSTERS);
    + /*
    + * Some AMD box with quadcore cpu and 8 sockets apicid
    + * will be [4, 0x23] or [8, 0x27] could be thought to
    + * have three apic_clusters. So go out early.
    + */
    + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
    + return 0;

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2

    On Sunday 24 February 2008 04:29:03 am Andi Kleen wrote:
    > On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote:
    > >
    > > quad core 8 socket system will have apic id lifting.the apic id range could
    > > be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
    > > and that is large than 2. So it is treated as clustered_box.

    >
    > Ok I see you chose the quick hack over doing it properly ...
    >
    > >
    > > and will get
    > >
    > > Marking TSC unstable due to TSCs unsynchronized
    > >
    > > even the CPUs have X86_FEATURE_CONSTANT_TSC set.

    >
    > I doubt that will do the right thing on AMD based vSMP,
    > which also required the cluster check on AMD iirc.
    >
    > Cc'ed Kiran/Shai. damage has already hit x86 tree I believe.


    do you have bootlog for these box?

    IBM summit2, Unisys es70000, and system from scalemp..

    DMI could tell the difference?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2

    On Sunday 24 February 2008 03:00:52 pm Yinghai Lu wrote:
    > On Sunday 24 February 2008 04:29:03 am Andi Kleen wrote:
    > > On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote:
    > > >
    > > > quad core 8 socket system will have apic id lifting.the apic id range could
    > > > be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
    > > > and that is large than 2. So it is treated as clustered_box.

    > >
    > > Ok I see you chose the quick hack over doing it properly ...
    > >
    > > >
    > > > and will get
    > > >
    > > > Marking TSC unstable due to TSCs unsynchronized
    > > >
    > > > even the CPUs have X86_FEATURE_CONSTANT_TSC set.

    > >
    > > I doubt that will do the right thing on AMD based vSMP,
    > > which also required the cluster check on AMD iirc.
    > >
    > > Cc'ed Kiran/Shai. damage has already hit x86 tree I believe.

    >
    > do you have bootlog for these box?
    >
    > IBM summit2, Unisys es70000, and system from scalemp..
    >
    > DMI could tell the difference?


    i produced one patch against linus tree. but it can not be applied to x86/testing

    x86/testing has
    obj-$(CONFIG_PARAVIRT) += vsmp_64.o

    so my question: is the vsmp the real HW or just in paravirt?

    YH

    ----

    [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v3

    quad core 8 socket system will have apic id lifting.the apic id range could
    be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
    and that is large than 2. So it is treated as clustered_box.

    and will get

    Marking TSC unstable due to TSCs unsynchronized

    even the CPUs have X86_FEATURE_CONSTANT_TSC set.

    this patch will check if the cpu is from AMD.

    also vsmp still need that checking...

    Signed-off-by: Yinghai Lu

    diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
    index 4eb5ce8..2bec799 100644
    --- a/arch/x86/kernel/Makefile
    +++ b/arch/x86/kernel/Makefile
    @@ -60,7 +60,7 @@ obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o
    obj-$(CONFIG_CRASH_DUMP) += crash_dump_$(BITS).o
    obj-$(CONFIG_X86_NUMAQ) += numaq_32.o
    obj-$(CONFIG_X86_SUMMIT_NUMA) += summit_32.o
    -obj-$(CONFIG_X86_VSMP) += vsmp_64.o
    +obj-y += vsmp_64.o
    obj-$(CONFIG_KPROBES) += kprobes.o
    obj-$(CONFIG_MODULES) += module_$(BITS).o
    obj-$(CONFIG_ACPI_SRAT) += srat_32.o
    diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
    index d8d03e0..1427ec3 100644
    --- a/arch/x86/kernel/apic_64.c
    +++ b/arch/x86/kernel/apic_64.c
    @@ -1180,9 +1180,20 @@ __cpuinit int apic_is_clustered_box(void)
    {
    int i, clusters, zeros;
    unsigned id;
    - u16 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
    + u16 *bios_cpu_apicid;
    DECLARE_BITMAP(clustermap, NUM_APIC_CLUSTERS);

    + /*
    + * there is not this kind of box with AMD CPU yet.
    + * Some AMD box with quadcore cpu and 8 sockets apicid
    + * will be [4, 0x23] or [8, 0x27] could be thought to
    + * have three apic_clusters. So go out early.
    + * vsmp box still need checking...
    + */
    + if (!is_vsmp_box() && (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
    + return 0;
    +
    + bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
    bitmap_zero(clustermap, NUM_APIC_CLUSTERS);

    for (i = 0; i < NR_CPUS; i++) {
    diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
    index d971210..2780df1 100644
    --- a/arch/x86/kernel/vsmp_64.c
    +++ b/arch/x86/kernel/vsmp_64.c
    @@ -16,19 +16,35 @@
    #include
    #include

    +static int vsmp = -1;
    +
    +__cpuinit int is_vsmp_box(void)
    +{
    + if (vsmp != -1)
    + return vsmp;
    +
    + vsmp = 0;
    + if (!early_pci_allowed())
    + return vsmp;
    +
    + /* Check if we are running on a ScaleMP vSMP box */
    + if (read_pci_config(0, 0x1f, 0, PCI_VENDOR_ID) ==
    + (PCI_VENDOR_ID_SCALEMP || (PCI_DEVICE_ID_SCALEMP_VSMP_CTL << 16)))
    + vsmp = 1;
    +
    + return vsmp;
    +}
    +
    +#ifdef CONFIG_X86_VSMP
    static int __init vsmp_init(void)
    {
    void *address;
    unsigned int cap, ctl;

    - if (!early_pci_allowed())
    + if (!vsmp)
    return 0;

    - /* Check if we are running on a ScaleMP vSMP box */
    - if ((read_pci_config_16(0, 0x1f, 0, PCI_VENDOR_ID) !=
    - PCI_VENDOR_ID_SCALEMP) ||
    - (read_pci_config_16(0, 0x1f, 0, PCI_DEVICE_ID) !=
    - PCI_DEVICE_ID_SCALEMP_VSMP_CTL))
    + if (!early_pci_allowed())
    return 0;

    /* set vSMP magic bits to indicate vSMP capable kernel */
    @@ -50,3 +66,4 @@ static int __init vsmp_init(void)
    }

    core_initcall(vsmp_init);
    +#endif
    diff --git a/include/asm-x86/apic.h b/include/asm-x86/apic.h
    index bcfc07f..d69f596 100644
    --- a/include/asm-x86/apic.h
    +++ b/include/asm-x86/apic.h
    @@ -130,6 +130,7 @@ extern u8 setup_APIC_eilvt_mce(u8 vector, u8 msg_type, u8 mask);
    extern u8 setup_APIC_eilvt_ibs(u8 vector, u8 msg_type, u8 mask);

    extern int apic_is_clustered_box(void);
    +extern int is_vsmp_box(void);

    #else /* !CONFIG_X86_LOCAL_APIC */
    static inline void lapic_shutdown(void) { }
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2

    please check the fix for v2.

    this one can be applied to x86.git#testing

    YH

    ---
    [PATCH] x86_64: apic_is_clustered_box fix for vsmp

    quad core 8 socket system will have apic id lifting.the apic id range could
    be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
    and that is large than 2. So it is treated as clustered_box.

    and will get

    Marking TSC unstable due to TSCs unsynchronized

    even the CPUs have X86_FEATURE_CONSTANT_TSC set.

    v2 patch will check if the cpu is from AMD.

    vsmp still need that checking...

    this patch is fix for vsmp

    Signed-off-by: Yinghai Lu

    diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
    index 8f6c45e..8a47579 100644
    --- a/arch/x86/kernel/apic_64.c
    +++ b/arch/x86/kernel/apic_64.c
    @@ -1206,9 +1206,9 @@ __cpuinit int apic_is_clustered_box(void)
    * there is not this kind of box with AMD CPU yet.
    * Some AMD box with quadcore cpu and 8 sockets apicid
    * will be [4, 0x23] or [8, 0x27] could be thought to
    - * have three apic_clusters. So go out early.
    + * vsmp box still need checking...
    */
    - if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
    + if (!is_vsmp_box() && (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
    return 0;

    bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
    diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
    index 54202b1..09e16ff 100644
    --- a/arch/x86/kernel/vsmp_64.c
    +++ b/arch/x86/kernel/vsmp_64.c
    @@ -72,19 +72,34 @@ static unsigned __init vsmp_patch(u8 type, u16 clobbers, void *ibuf,

    }

    +static int vsmp = -1;
    +
    +int is_vsmp_box(void)
    +{
    + if (vsmp != -1)
    + return vsmp;
    +
    + vsmp = 0;
    + if (!early_pci_allowed())
    + return vsmp;
    +
    + /* Check if we are running on a ScaleMP vSMP box */
    + if (read_pci_config(0, 0x1f, 0, PCI_VENDOR_ID) ==
    + (PCI_VENDOR_ID_SCALEMP || (PCI_DEVICE_ID_SCALEMP_VSMP_CTL << 16)))
    + vsmp = 1;
    +
    + return vsmp;
    +}
    +
    void __init vsmp_init(void)
    {
    void *address;
    unsigned int cap, ctl, cfg;

    - if (!early_pci_allowed())
    + if (!vsmp)
    return;

    - /* Check if we are running on a ScaleMP vSMP box */
    - if ((read_pci_config_16(0, 0x1f, 0, PCI_VENDOR_ID) !=
    - PCI_VENDOR_ID_SCALEMP) ||
    - (read_pci_config_16(0, 0x1f, 0, PCI_DEVICE_ID) !=
    - PCI_DEVICE_ID_SCALEMP_VSMP_CTL))
    + if (!early_pci_allowed())
    return;

    /* If we are, use the distinguished irq functions */
    diff --git a/include/asm-x86/apic.h b/include/asm-x86/apic.h
    index a68dc6b..24f7a05 100644
    --- a/include/asm-x86/apic.h
    +++ b/include/asm-x86/apic.h
    @@ -51,12 +51,17 @@ extern unsigned boot_cpu_id;
    */
    #ifdef CONFIG_PARAVIRT
    #include
    +extern int is_vsmp_box(void);
    #else
    #define apic_write native_apic_write
    #define apic_write_atomic native_apic_write_atomic
    #define apic_read native_apic_read
    #define setup_boot_clock setup_boot_APIC_clock
    #define setup_secondary_clock setup_secondary_APIC_clock
    +int inline is_vsmp_box(void)
    +{
    + return 0;
    +}
    #endif

    static inline void native_apic_write(unsigned long reg, u32 v)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. [PATCH] x86_64: for apic_is_clustered_box for vsmp v2


    quad core 8 socket system will have apic id lifting.the apic id range could
    be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
    and that is large than 2. So it is treated as clustered_box.

    and will get

    Marking TSC unstable due to TSCs unsynchronized

    even the CPUs have X86_FEATURE_CONSTANT_TSC set.

    quick fixwill check if the cpu is from AMD.

    but vsmp still need that checking...

    this patch is fix to make sure that vsmp not to be passed.

    and need to be applied after
    x86_64: make amd quad core 8 socket system not be clustered_box v2
    in x86/testing

    Signed-off-by: Yinghai Lu

    Index: linux-2.6/arch/x86/kernel/apic_64.c
    ================================================== =================
    --- linux-2.6.orig/arch/x86/kernel/apic_64.c
    +++ linux-2.6/arch/x86/kernel/apic_64.c
    @@ -1206,9 +1206,9 @@ __cpuinit int apic_is_clustered_box(void
    * there is not this kind of box with AMD CPU yet.
    * Some AMD box with quadcore cpu and 8 sockets apicid
    * will be [4, 0x23] or [8, 0x27] could be thought to
    - * have three apic_clusters. So go out early.
    + * vsmp box still need checking...
    */
    - if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
    + if (!is_vsmp_box() && (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
    return 0;

    bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
    Index: linux-2.6/arch/x86/kernel/vsmp_64.c
    ================================================== =================
    --- linux-2.6.orig/arch/x86/kernel/vsmp_64.c
    +++ linux-2.6/arch/x86/kernel/vsmp_64.c
    @@ -72,19 +72,34 @@ static unsigned __init vsmp_patch(u8 typ

    }

    +static int vsmp = -1;
    +
    +int is_vsmp_box(void)
    +{
    + if (vsmp != -1)
    + return vsmp;
    +
    + vsmp = 0;
    + if (!early_pci_allowed())
    + return vsmp;
    +
    + /* Check if we are running on a ScaleMP vSMP box */
    + if (read_pci_config(0, 0x1f, 0, PCI_VENDOR_ID) ==
    + (PCI_VENDOR_ID_SCALEMP || (PCI_DEVICE_ID_SCALEMP_VSMP_CTL << 16)))
    + vsmp = 1;
    +
    + return vsmp;
    +}
    +
    void __init vsmp_init(void)
    {
    void *address;
    unsigned int cap, ctl, cfg;

    - if (!early_pci_allowed())
    + if (!is_vsmp_box())
    return;

    - /* Check if we are running on a ScaleMP vSMP box */
    - if ((read_pci_config_16(0, 0x1f, 0, PCI_VENDOR_ID) !=
    - PCI_VENDOR_ID_SCALEMP) ||
    - (read_pci_config_16(0, 0x1f, 0, PCI_DEVICE_ID) !=
    - PCI_DEVICE_ID_SCALEMP_VSMP_CTL))
    + if (!early_pci_allowed())
    return;

    /* If we are, use the distinguished irq functions */
    Index: linux-2.6/include/asm-x86/apic.h
    ================================================== =================
    --- linux-2.6.orig/include/asm-x86/apic.h
    +++ linux-2.6/include/asm-x86/apic.h
    @@ -51,12 +51,17 @@ extern unsigned boot_cpu_id;
    */
    #ifdef CONFIG_PARAVIRT
    #include
    +extern int is_vsmp_box(void);
    #else
    #define apic_write native_apic_write
    #define apic_write_atomic native_apic_write_atomic
    #define apic_read native_apic_read
    #define setup_boot_clock setup_boot_APIC_clock
    #define setup_secondary_clock setup_secondary_APIC_clock
    +static int inline is_vsmp_box(void)
    +{
    + return 0;
    +}
    #endif

    static inline void native_apic_write(unsigned long reg, u32 v)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2

    On Sun, Feb 24, 2008 at 4:29 AM, Andi Kleen wrote:
    > On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote:
    > >
    > > quad core 8 socket system will have apic id lifting.the apic id range could
    > > be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
    > > and that is large than 2. So it is treated as clustered_box.

    >
    > Ok I see you chose the quick hack over doing it properly ...


    you didn't answer my question:

    for IBM Summit2, Unisys ES7000, and ScaleMP vSMP,
    if call cpus sockets are fully populated with quadcore cpus, do they
    still have hole between apic id?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. [PATCH] x86: vSMP selection in config


    find out vSMP setting is going away in config after make oldconfig

    vSMP need to PARAVIRT and PCI.
    so move PARAVIRT out of if PARAVIRT_GUEST, and make vSMP select PCI instead of
    depends on PCI

    after patch vSMP could stick there.

    Signed-off-by: Yinghai Lu

    Index: linux-2.6/arch/x86/Kconfig
    ================================================== =================
    --- linux-2.6.orig/arch/x86/Kconfig
    +++ linux-2.6/arch/x86/Kconfig
    @@ -330,8 +330,9 @@ config X86_RDC321X

    config X86_VSMP
    bool "Support for ScaleMP vSMP"
    - depends on X86_64 && PCI
    + depends on X86_64
    select PARAVIRT
    + select PCI
    help
    Support for ScaleMP vSMP systems. Say 'Y' here if this kernel is
    supposed to run on these EM64T-based machines. Only choose this option
    @@ -376,6 +377,8 @@ config VMI

    source "arch/x86/lguest/Kconfig"

    +endif
    +
    config PARAVIRT
    bool "Enable paravirtualization code"
    depends on !(X86_VISWS || X86_VOYAGER)
    @@ -385,8 +388,6 @@ config PARAVIRT
    over full virtualization. However, when run without a hypervisor
    the kernel is theoretically slower and slightly larger.

    -endif
    -
    config ACPI_SRAT
    def_bool y
    depends on X86_32 && ACPI && NUMA && (X86_SUMMIT || X86_GENERICARCH)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast