| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [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.
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home