[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible
On Wed, 4 Feb 2015, parth.dixit@xxxxxxxxxx wrote: > From: Naresh Bhat <naresh.bhat@xxxxxxxxxx> > > Introduce and use cpumask_next_zero, set_cpu_present and set_cpu_possible. > > Signed-off-by: Naresh Bhat <naresh.bhat@xxxxxxxxxx> > --- > xen/common/cpu.c | 18 ++++++++++++++++++ > xen/include/xen/cpumask.h | 40 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 58 insertions(+) > > diff --git a/xen/common/cpu.c b/xen/common/cpu.c > index 630881e..da399c9 100644 > --- a/xen/common/cpu.c > +++ b/xen/common/cpu.c > @@ -216,3 +216,21 @@ void enable_nonboot_cpus(void) > > cpumask_clear(&frozen_cpus); > } > + > +static DECLARE_BITMAP(cpu_present_bits, NR_CPUS) __read_mostly; We already have cpu_present_map on both x86 and ARM. Does it make sense to use that instead? > +static DECLARE_BITMAP(cpu_possible_bits, NR_CPUS) __read_mostly; ARM already has cpu_possible_map. x86 seems to be able to cope with having ACPI without this map. If you want to introduce it, you should explain why x86 needs this map. > +void set_cpu_possible(unsigned int cpu, bool possible) > +{ > + if ( possible ) > + cpumask_set_cpu(cpu, to_cpumask(cpu_possible_bits)); > + else > + cpumask_clear_cpu(cpu, to_cpumask(cpu_possible_bits)); > +} > + > +void set_cpu_present(unsigned int cpu, bool present) > +{ > + if ( present ) > + cpumask_set_cpu(cpu, to_cpumask(cpu_present_bits)); > + else > + cpumask_clear_cpu(cpu, to_cpumask(cpu_present_bits)); > +} > diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h > index 850b4a2..209483e 100644 > --- a/xen/include/xen/cpumask.h > +++ b/xen/include/xen/cpumask.h > @@ -78,6 +78,7 @@ > #include <xen/bitmap.h> > #include <xen/kernel.h> > #include <xen/random.h> > +#include <xen/stdbool.h> > > typedef struct cpumask{ DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t; > > @@ -295,6 +296,22 @@ static inline int cpulist_scnprintf(char *buf, int len, > } > > /* > + * cpumask_next_zero - get the next unset cpu in a cpumask > + * @n: the cpu prior to the place to search (ie. return will be > @n) > + * @srcp: the cpumask pointer > + * > + * Returns >= nr_cpu_ids if no further cpus unset. > + */ > +static inline unsigned int cpumask_next_zero(int n, const cpumask_t *srcp) > +{ > + /* -1 is a legal arg here. */ > + if (n != -1) > + cpumask_check(n); > + > + return find_next_zero_bit(srcp->bits, nr_cpu_ids, n+1); return min_t(int, nr_cpu_ids, find_next_zero_bit(srcp->bits, nr_cpu_ids, n + 1)); > +} > + > +/* > * cpumask_var_t: struct cpumask for stack usage. > * > * Oh, the wicked games we play! In order to make kernel coding a > @@ -440,6 +457,29 @@ extern cpumask_t cpu_present_map; > #define for_each_online_cpu(cpu) for_each_cpu(cpu, &cpu_online_map) > #define for_each_present_cpu(cpu) for_each_cpu(cpu, &cpu_present_map) > > +/* Wrappers for arch boot code to manipulate normally-constant masks */ > +void set_cpu_possible(unsigned int cpu, bool possible); > +void set_cpu_present(unsigned int cpu, bool present); > + > +/* > + * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask * > + * @bitmap: the bitmap > + * > + * There are a few places where cpumask_var_t isn't appropriate and > + * static cpumasks must be used (eg. very early boot), yet we don't > + * expose the definition of 'struct cpumask'. > + * > + * This does the conversion, and can be used as a constant initializer. > + */ > +#define to_cpumask(bitmap) \ > + ((struct cpumask *)(1 ? (bitmap) \ it doesn't make sense to me > + : (void *)sizeof(__check_is_bitmap(bitmap)))) > + > +static inline int __check_is_bitmap(const unsigned long *bitmap) > +{ > + return 1; > +} What is the purpose of this? > /* Copy to/from cpumap provided by control tools. */ > struct xenctl_bitmap; > int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *); > -- > 1.9.1 > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |