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

2008-02-26 Thread Ravikiran Thirumalai
On Mon, Feb 25, 2008 at 09:27:42PM -0800, Yinghai Lu wrote: >On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai <[EMAIL PROTECTED]> >wrote: >> On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: >> >> > >> >If you can't support that in y

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

2008-02-26 Thread Ravikiran Thirumalai
On Mon, Feb 25, 2008 at 09:27:42PM -0800, Yinghai Lu wrote: On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: If you can't support that in your hardware you're supposed to clear it. Hmm! How would

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

2008-02-25 Thread Ravikiran Thirumalai
On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: >> I don't quite understand the purpose of the patch to begin with. Looking at >> the current x86 git tree, apic_is_clustered_box is used only to determine if >> tsc is synchronized on the platform. The AMD docs imply that TSC's are

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

2008-02-25 Thread Ravikiran Thirumalai
On Mon, Feb 25, 2008 at 02:05:45PM -0800, Yinghai Lu wrote: >On Mon, Feb 25, 2008 at 11:08 AM, Ravikiran Thirumalai ><[EMAIL PROTECTED]> wrote: >> ... >> Andi, Yes. AMD based vSMPowered systems uses clustered APICs, and this >> check base on cpu vendor id is not g

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

2008-02-25 Thread Ravikiran Thirumalai
On Sun, Feb 24, 2008 at 01:29:03PM +0100, 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

Re: defconfig's for all x86 subarchitectures

2008-02-25 Thread Ravikiran Thirumalai
On Sun, Feb 24, 2008 at 09:40:39PM +0100, Sam Ravnborg wrote: >On Sun, Feb 24, 2008 at 10:16:34PM +0200, Adrian Bunk wrote: >> For compile tests it would be nice it we had at least for each >> subarchitecture not covered by X86_GENERICARCH a defconfig. >> >> These are the following

Re: defconfig's for all x86 subarchitectures

2008-02-25 Thread Ravikiran Thirumalai
On Sun, Feb 24, 2008 at 09:40:39PM +0100, Sam Ravnborg wrote: On Sun, Feb 24, 2008 at 10:16:34PM +0200, Adrian Bunk wrote: For compile tests it would be nice it we had at least for each subarchitecture not covered by X86_GENERICARCH a defconfig. These are the following subarchitectures: -

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

2008-02-25 Thread Ravikiran Thirumalai
On Sun, Feb 24, 2008 at 01:29:03PM +0100, 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

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

2008-02-25 Thread Ravikiran Thirumalai
On Mon, Feb 25, 2008 at 02:05:45PM -0800, Yinghai Lu wrote: On Mon, Feb 25, 2008 at 11:08 AM, Ravikiran Thirumalai [EMAIL PROTECTED] wrote: ... Andi, Yes. AMD based vSMPowered systems uses clustered APICs, and this check base on cpu vendor id is not good :(. please check if you happy

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

2008-02-25 Thread Ravikiran Thirumalai
On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: I don't quite understand the purpose of the patch to begin with. Looking at the current x86 git tree, apic_is_clustered_box is used only to determine if tsc is synchronized on the platform. The AMD docs imply that TSC's are not

Re: [PATCH 4/5] [PATCH] introduce paravirt helpers

2008-02-19 Thread Ravikiran Thirumalai
On Sun, Feb 17, 2008 at 06:56:56PM -0200, Glauber Costa wrote: >On Feb 17, 2008 4:05 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: >> >> * Glauber Costa <[EMAIL PROTECTED]> wrote: >> >> > config X86_VSMP >> > bool "Support for ScaleMP vSMP" >> > depends on X86_64 && PCI >> > - help

Re: [PATCH 4/5] [PATCH] introduce paravirt helpers

2008-02-19 Thread Ravikiran Thirumalai
On Sun, Feb 17, 2008 at 06:56:56PM -0200, Glauber Costa wrote: On Feb 17, 2008 4:05 PM, Ingo Molnar [EMAIL PROTECTED] wrote: * Glauber Costa [EMAIL PROTECTED] wrote: config X86_VSMP bool Support for ScaleMP vSMP depends on X86_64 PCI - help + select PARAVIRT +

Re: [PATCH 24/24] make vsmp a paravirt client

2007-11-13 Thread Ravikiran Thirumalai
On Tue, Nov 13, 2007 at 02:09:41PM +0100, Andi Kleen wrote: > >> If vsmp is selected, PARAVIRT will be too, and the interrupt code will >> be patched. >> the vsmp option triggers a select statement. >> >> the ifdef only exists because, as I said, the code itself will be always >> compiled in, to

Re: [PATCH 24/24] make vsmp a paravirt client

2007-11-13 Thread Ravikiran Thirumalai
On Tue, Nov 13, 2007 at 09:36:42AM -0200, Glauber de Oliveira Costa wrote: >-BEGIN PGP SIGNED MESSAGE- > >> And the "EM64T based comment" is wrong because there are AMD based >> vSMPs too. >Just got it as-is from the old Kconfig. Do you think it should be fixed >as well? Yep. Thanks,

Re: [PATCH 24/24] make vsmp a paravirt client

2007-11-13 Thread Ravikiran Thirumalai
On Tue, Nov 13, 2007 at 09:36:42AM -0200, Glauber de Oliveira Costa wrote: -BEGIN PGP SIGNED MESSAGE- And the EM64T based comment is wrong because there are AMD based vSMPs too. Just got it as-is from the old Kconfig. Do you think it should be fixed as well? Yep. Thanks, Kiran - To

Re: [PATCH 24/24] make vsmp a paravirt client

2007-11-13 Thread Ravikiran Thirumalai
On Tue, Nov 13, 2007 at 02:09:41PM +0100, Andi Kleen wrote: If vsmp is selected, PARAVIRT will be too, and the interrupt code will be patched. the vsmp option triggers a select statement. the ifdef only exists because, as I said, the code itself will be always compiled in, to avoid an