Xen devel - Apr 2005 - [PATCH] For running Xen on a 32-way system

Here is a patch to get Xen running on a 32-way Unisys ES7000 system.
Please note that this patch alone is not sufficient to do this. You will
also need the clustered APIC patch that I will be submitting soon. But
since this patch was to a general area in Xen I decided to submit it
separately. I think this patch will be required to get Xen running on
any system that has more than 16 CPUs. 

Here are the following things I did along with the questions I have:

1. I bumped up NR_CPUS to 32 in include/asm-x86/config.h. Is this value
high enough? I know there are some big systems out there. Should this be
bumped up to 64 or 128?

2. Increasing the value of NR_CPUS caused the system to die while
bringing up the 17th CPU. Digging into this I found that the GDT limit
was hard coded for a 16-way. To fix this I had to increase the value of
NR_RESERVED_GDT_ENTRIES in include/public/arch-x86_xx.h. (I am assuming
that NR_RESERVED_GDT_ENTRIES is set by the formula 2*NR_CPUS+8 for
x86_32 and 4*NR_CPUS+8 for x86_64) It seems that there is no correlation
between the two headers, arch-x86_xx.h and config.h. For now I have
explained the correlation with a comment. Should this correlation be
checked somehow at compile time?

3. Should the GDT limit be checked while the system is booting against
the number of CPUs so that the system dies with an appropriate message
rather than just dying while trying to bring up the NR_CPUS+1th CPU?
Will this patch be useful or would it be over kill?

Signed off by Aravindh Puthiyaparambil
<aravindh.puthiyaparambil@unisys.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> Here is a patch to get Xen running on a 32-way Unisys ES7000 system.
> Please note that this patch alone is not sufficient to do 
> this. You will also need the clustered APIC patch that I will 
> be submitting soon. But since this patch was to a general 
> area in Xen I decided to submit it separately. I think this 
> patch will be required to get Xen running on any system that 
> has more than 16 CPUs. 
Thanks for the patch.
> Here are the following things I did along with the questions I have:
> 
> 1. I bumped up NR_CPUS to 32 in include/asm-x86/config.h. Is 
> this value high enough? I know there are some big systems out 
> there. Should this be bumped up to 64 or 128?
We''ll need to create a cpu_set_t for storing cpu bit maps and audit the
code -- there are currently a bunch of assumptions that the bitmap will
fit in a long.
> 2. Increasing the value of NR_CPUS caused the system to die 
> while bringing up the 17th CPU. Digging into this I found 
> that the GDT limit was hard coded for a 16-way. To fix this I 
> had to increase the value of NR_RESERVED_GDT_ENTRIES in 
> include/public/arch-x86_xx.h. (I am assuming that 
> NR_RESERVED_GDT_ENTRIES is set by the formula 2*NR_CPUS+8 for
> x86_32 and 4*NR_CPUS+8 for x86_64) It seems that there is no 
> correlation between the two headers, arch-x86_xx.h and 
> config.h. For now I have explained the correlation with a 
> comment. Should this correlation be checked somehow at compile time?
Good spot.
> Will this patch be useful or would it be over kill?
I think large SMP should be a compile time option for the moment. The
important thing to get right is that the hypervisor interface shouldn''t
need to change. (I know a couple of the ''long'' assumptions are
in the
public API, and need fixing). Patches welcome :-)

Thanks,
Ian




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel