this is the next version of my patches to support cpupools in xl/libxl. For full functionality it is necessary to change cpumask handling for cpupools in libxc (patch 1). Patch 2 adds the full cpupool support in xl. Patch 3 adds an example configuration file for xm/xl pool-create. Changes since last version: requests of Ian Campbell 19 files changed, 1020 insertions(+), 238 deletions(-) tools/examples/README | 1 tools/examples/cpupool | 18 + tools/libxc/xc_cpupool.c | 118 +++++--- tools/libxc/xc_misc.c | 14 + tools/libxc/xenctrl.h | 26 - tools/libxl/libxl.c | 252 ++++++++++++++++-- tools/libxl/libxl.h | 13 tools/libxl/libxl.idl | 16 - tools/libxl/libxl_internal.h | 3 tools/libxl/libxl_utils.c | 93 +++++- tools/libxl/libxl_utils.h | 10 tools/libxl/libxltypes.py | 5 tools/libxl/libxlu_cfg_l.c | 30 -- tools/libxl/libxlu_cfg_l.h | 18 - tools/libxl/xl.h | 6 tools/libxl/xl_cmdimpl.c | 494 +++++++++++++++++++++++++++++++++++-- tools/libxl/xl_cmdtable.c | 35 ++ tools/python/xen/lowlevel/xc/xc.c | 96 ++----- tools/python/xen/lowlevel/xl/xl.c | 10 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen Gross
2010-Oct-05 13:45 UTC
[Xen-devel] [PATCH 1 of 3] To be able to support arbitrary numbers of physical cpus it was necessary to
include the size of cpumaps in the xc-interfaces for cpu pools. These were: definition of xc_cpupoolinfo_t xc_cpupool_getinfo() xc_cpupool_freeinfo() xc_cpupool_getinfo() and xc_cpupool_freeinfo() are changed to allocate the needed buffer and return it. Signed-off-by: juergen.gross@ts.fujitsu.com 7 files changed, 174 insertions(+), 152 deletions(-) tools/libxc/xc_cpupool.c | 118 ++++++++++++++++++++++--------------- tools/libxc/xc_misc.c | 14 ++++ tools/libxc/xenctrl.h | 26 ++++---- tools/libxl/libxl.c | 49 +++++++-------- tools/libxl/libxl_internal.h | 1 tools/libxl/xl_cmdimpl.c | 22 +++--- tools/python/xen/lowlevel/xc/xc.c | 96 ++++++++++++------------------ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen Gross
2010-Oct-05 13:45 UTC
[Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes
Support of cpu pools in xl: library functions xl pool-create xl pool-list xl pool-destroy xl pool-cpu-add xl pool-cpu-remove xl pool-migrate Renamed all cpu pool related names to *cpupool* Signed-off-by: juergen.gross@ts.fujitsu.com 13 files changed, 827 insertions(+), 86 deletions(-) tools/libxl/libxl.c | 203 +++++++++++++++ tools/libxl/libxl.h | 13 - tools/libxl/libxl.idl | 16 - tools/libxl/libxl_internal.h | 2 tools/libxl/libxl_utils.c | 93 ++++++- tools/libxl/libxl_utils.h | 10 tools/libxl/libxltypes.py | 5 tools/libxl/libxlu_cfg_l.c | 30 -- tools/libxl/libxlu_cfg_l.h | 18 - tools/libxl/xl.h | 6 tools/libxl/xl_cmdimpl.c | 472 ++++++++++++++++++++++++++++++++++++- tools/libxl/xl_cmdtable.c | 35 ++ tools/python/xen/lowlevel/xl/xl.c | 10 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen Gross
2010-Oct-05 13:45 UTC
[Xen-devel] [PATCH 3 of 3] add example cpupool config file
Adds an example configuration file for xm/xl pool-create Signed-off-by: juergen.gross@ts.fujitsu.com 2 files changed, 19 insertions(+) tools/examples/README | 1 + tools/examples/cpupool | 18 ++++++++++++++++++ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2010-Oct-06 11:21 UTC
Re: [Xen-devel] [PATCH 1 of 3] To be able to support arbitrary numbers of physical cpus it was necessary to
On Tue, 5 Oct 2010, Juergen Gross wrote:> diff -r fe3018c6976d -r cfce8e755505 tools/libxl/libxl_internal.h > --- a/tools/libxl/libxl_internal.h Mon Oct 04 12:52:14 2010 +0100 > +++ b/tools/libxl/libxl_internal.h Tue Oct 05 14:19:13 2010 +0200 > @@ -239,7 +239,6 @@ > _hidden char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid); > _hidden char *libxl__poolid_to_name(libxl__gc *gc, uint32_t poolid); > > - > /* holds the CPUID response for a single CPUID leaf > * input contains the value of the EAX and ECX register, > * and each policy string contains a filter to apply towe don''t need this change> diff -r fe3018c6976d -r cfce8e755505 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c Mon Oct 04 12:52:14 2010 +0100 > +++ b/tools/libxl/xl_cmdimpl.c Tue Oct 05 14:19:13 2010 +0200 > @@ -3616,12 +3616,11 @@ > static void vcpupin(char *d, const char *vcpu, char *cpu) > { > libxl_vcpuinfo *vcpuinfo; > - libxl_physinfo physinfo; > uint64_t *cpumap = NULL; > > uint32_t vcpuid, cpuida, cpuidb; > char *endptr, *toka, *tokb; > - int i, nb_vcpu, cpusize; > + int i, nb_vcpu, cpusize, cpumapsize; > > vcpuid = strtoul(vcpu, &endptr, 10); > if (vcpu == endptr) { > @@ -3634,12 +3633,13 @@ > > find_domain(d); > > - if (libxl_get_physinfo(&ctx, &physinfo) != 0) { > - fprintf(stderr, "libxl_get_physinfo failed.\n"); > + if ((cpusize = xc_get_max_cpus(ctx.xch)) == 0) { > + fprintf(stderr, "xc_get_maxcpus failed.\n"); > goto vcpupin_out1; > }You shouldn''t be calling xc functions directly from xl_cmdimpl.c. The basic rule is: libxl clients (such as xl) shouldn''t need to call any library functions other than libxenlight''s functions. You can add a libxl_get_max_cpus function though. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2010-Oct-06 11:25 UTC
Re: [Xen-devel] [PATCH 3 of 3] add example cpupool config file
On Tue, 5 Oct 2010, Juergen Gross wrote:> Adds an example configuration file for xm/xl pool-create > > Signed-off-by: juergen.gross@ts.fujitsu.com > > > 2 files changed, 19 insertions(+) > tools/examples/README | 1 + > tools/examples/cpupool | 18 ++++++++++++++++++ > > # HG changeset patch > # User Juergen Gross <juergen.gross@ts.fujitsu.com> > # Date 1286286221 -7200 > # Node ID bf1b8d1bb6f723b1541699156c6a24d8fc45c843 > # Parent baee85a244118f3808082358da3ccc5191d7ffd6 > add example cpupool config file > > Adds an example configuration file for xm/xl pool-create > > Signed-off-by: juergen.gross@ts.fujitsu.com > > diff -r baee85a24411 -r bf1b8d1bb6f7 tools/examples/README > --- a/tools/examples/README Tue Oct 05 15:26:24 2010 +0200 > +++ b/tools/examples/README Tue Oct 05 15:43:41 2010 +0200 > @@ -13,6 +13,7 @@ > block-common.sh - sourced by block, block-* > block-enbd - binds/unbinds network block devices > block-nbd - binds/unbinds network block devices > +cpupool - example configuration script for ''xm pool-create'' > external-device-migrate - called by xend for migrating external devices > locking.sh - locking functions to prevent concurrent access to > critical sections inside script files > diff -r baee85a24411 -r bf1b8d1bb6f7 tools/examples/cpupool > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/tools/examples/cpupool Tue Oct 05 15:43:41 2010 +0200 > @@ -0,0 +1,18 @@ > +# -*- mode: python; -*- > +#===========================================================================> +# Python configuration setup for ''xm pool-create''. > +# This script sets the parameters used when a cpupool is created using > +# ''xm pool-create''. > +# You use a separate script for each cpupool you want to create, or > +# you can set the parameters for the cpupool on the xm command line. > +#===========================================================================> +Considering that this example file is supposed to work with xl too I would recommend to remove the mode: python line that is not needed anyway and all the other Python references in the comment. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2010-Oct-06 13:26 UTC
Re: [Xen-devel] [PATCH 1 of 3] To be able to support arbitrary numbers of physical cpus it was necessary to
On Tue, 2010-10-05 at 14:45 +0100, Juergen Gross wrote:> include the size of cpumaps in the xc-interfaces for cpu pools. > These were: > definition of xc_cpupoolinfo_t > xc_cpupool_getinfo() > xc_cpupool_freeinfo() > xc_cpupool_getinfo() and xc_cpupool_freeinfo() are changed to allocate the > needed buffer and return it. > > Signed-off-by: juergen.gross@ts.fujitsu.comOther than the comments Stefano made this looks good to me, thanks Juergen. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2010-Oct-06 13:31 UTC
Re: [Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes
On Tue, 2010-10-05 at 14:45 +0100, Juergen Gross wrote:> Support of cpu pools in xl: > library functions > xl pool-create > xl pool-list > xl pool-destroy > xl pool-cpu-add > xl pool-cpu-remove > xl pool-migrate > Renamed all cpu pool related names to *cpupool* > > Signed-off-by: juergen.gross@ts.fujitsu.comAcked-by: Ian Campbell <ian.campbell@citrix.com>> > > 13 files changed, 827 insertions(+), 86 deletions(-) > tools/libxl/libxl.c | 203 +++++++++++++++ > tools/libxl/libxl.h | 13 - > tools/libxl/libxl.idl | 16 - > tools/libxl/libxl_internal.h | 2 > tools/libxl/libxl_utils.c | 93 ++++++- > tools/libxl/libxl_utils.h | 10 > tools/libxl/libxltypes.py | 5 > tools/libxl/libxlu_cfg_l.c | 30 -- > tools/libxl/libxlu_cfg_l.h | 18 - > tools/libxl/xl.h | 6 > tools/libxl/xl_cmdimpl.c | 472 ++++++++++++++++++++++++++++++++++++- > tools/libxl/xl_cmdtable.c | 35 ++ > tools/python/xen/lowlevel/xl/xl.c | 10 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2010-Oct-06 13:41 UTC
Re: [Xen-devel] [PATCH 1 of 3] To be able to support arbitrary numbers of physical cpus it was necessary to
On Wed, 2010-10-06 at 12:21 +0100, Stefano Stabellini wrote:> On Tue, 5 Oct 2010, Juergen Gross wrote: > > diff -r fe3018c6976d -r cfce8e755505 tools/libxl/libxl_internal.h > > --- a/tools/libxl/libxl_internal.h Mon Oct 04 12:52:14 2010 +0100 > > +++ b/tools/libxl/libxl_internal.h Tue Oct 05 14:19:13 2010 +0200 > > @@ -239,7 +239,6 @@ > > _hidden char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid); > > _hidden char *libxl__poolid_to_name(libxl__gc *gc, uint32_t poolid); > > > > - > > /* holds the CPUID response for a single CPUID leaf > > * input contains the value of the EAX and ECX register, > > * and each policy string contains a filter to apply to > > we don''t need this change > > > > diff -r fe3018c6976d -r cfce8e755505 tools/libxl/xl_cmdimpl.c > > --- a/tools/libxl/xl_cmdimpl.c Mon Oct 04 12:52:14 2010 +0100 > > +++ b/tools/libxl/xl_cmdimpl.c Tue Oct 05 14:19:13 2010 +0200 > > @@ -3616,12 +3616,11 @@ > > static void vcpupin(char *d, const char *vcpu, char *cpu) > > { > > libxl_vcpuinfo *vcpuinfo; > > - libxl_physinfo physinfo; > > uint64_t *cpumap = NULL; > > > > uint32_t vcpuid, cpuida, cpuidb; > > char *endptr, *toka, *tokb; > > - int i, nb_vcpu, cpusize; > > + int i, nb_vcpu, cpusize, cpumapsize; > > > > vcpuid = strtoul(vcpu, &endptr, 10); > > if (vcpu == endptr) { > > @@ -3634,12 +3633,13 @@ > > > > find_domain(d); > > > > - if (libxl_get_physinfo(&ctx, &physinfo) != 0) { > > - fprintf(stderr, "libxl_get_physinfo failed.\n"); > > + if ((cpusize = xc_get_max_cpus(ctx.xch)) == 0) { > > + fprintf(stderr, "xc_get_maxcpus failed.\n"); > > goto vcpupin_out1; > > } > > You shouldn''t be calling xc functions directly from xl_cmdimpl.c. > The basic rule is: libxl clients (such as xl) shouldn''t need to call any > library functions other than libxenlight''s functions. > You can add a libxl_get_max_cpus function though.Maybe we should add libxl_cpumap_alloc_phys which returns a libxl_cpumap big enough to hold all physical CPUs, there are a few places within libxl itself which might benefit from this, e.g. libxl_list_cpupool and libxl_list_vcpu both call xc_get_max_cpus and then use the result as a parameter to libxl_cpumap_alloc. Actually, given that libxl_cpumap is only ever used for PCPUs perhaps alloc should just always return a suitably sized map and there''s no need for the size parameter to libxl_cpumap_alloc? Is there any plausible potential use for a libxl_cpumap of nrVCPU rather than nrPCPU ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Gianni Tedesco
2010-Oct-06 13:47 UTC
Re: [Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes
On Tue, 2010-10-05 at 14:45 +0100, Juergen Gross wrote:> diff -r cfce8e755505 -r baee85a24411 tools/python/xen/lowlevel/xl/xl.c > --- a/tools/python/xen/lowlevel/xl/xl.c Tue Oct 05 14:19:13 2010 +0200 > +++ b/tools/python/xen/lowlevel/xl/xl.c Tue Oct 05 15:26:24 2010 +0200 > @@ -208,6 +208,11 @@ > return -1; > } > > +int attrib__uint64_t_ptr_set(PyObject *v, uint64_t * *pptr) > +{ > + return -1; > +} > + > int attrib__libxl_cpumap_set(PyObject *v, libxl_cpumap *pptr) > { > return -1; > @@ -254,6 +259,11 @@ > } > > PyObject *attrib__libxl_cpuid_policy_list_get(libxl_cpuid_policy_list > *pptr) > +{ > + return NULL; > +} > + > +PyObject *attrib__uint64_t_ptr_get(uint64_t * *pptr) > { > return NULL; > }Because of using Reference(Uint64) directly in the idl - the python bindings autogenerate these type-marshalling functions. It''s not quite clear how these are supposed to be implemented in a generic way! :) There ought to be a builtin type for this ala libxl_uuid and other types to generate correct bindings. The other chunk to libxltypes then becomes redundant but it''s OK with me I think. NAK''d-by: Gianni Tedesco <gianni.tedesco@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen Gross
2010-Oct-08 08:03 UTC
Re: [Xen-devel] [PATCH 1 of 3] To be able to support arbitrary numbers of physical cpus it was necessary to
On 10/06/10 15:41, Ian Campbell wrote:> On Wed, 2010-10-06 at 12:21 +0100, Stefano Stabellini wrote: >> On Tue, 5 Oct 2010, Juergen Gross wrote: >>> diff -r fe3018c6976d -r cfce8e755505 tools/libxl/libxl_internal.h >>> --- a/tools/libxl/libxl_internal.h Mon Oct 04 12:52:14 2010 +0100 >>> +++ b/tools/libxl/libxl_internal.h Tue Oct 05 14:19:13 2010 +0200 >>> @@ -239,7 +239,6 @@ >>> _hidden char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid); >>> _hidden char *libxl__poolid_to_name(libxl__gc *gc, uint32_t poolid); >>> >>> - >>> /* holds the CPUID response for a single CPUID leaf >>> * input contains the value of the EAX and ECX register, >>> * and each policy string contains a filter to apply to >> >> we don''t need this change >> >> >>> diff -r fe3018c6976d -r cfce8e755505 tools/libxl/xl_cmdimpl.c >>> --- a/tools/libxl/xl_cmdimpl.c Mon Oct 04 12:52:14 2010 +0100 >>> +++ b/tools/libxl/xl_cmdimpl.c Tue Oct 05 14:19:13 2010 +0200 >>> @@ -3616,12 +3616,11 @@ >>> static void vcpupin(char *d, const char *vcpu, char *cpu) >>> { >>> libxl_vcpuinfo *vcpuinfo; >>> - libxl_physinfo physinfo; >>> uint64_t *cpumap = NULL; >>> >>> uint32_t vcpuid, cpuida, cpuidb; >>> char *endptr, *toka, *tokb; >>> - int i, nb_vcpu, cpusize; >>> + int i, nb_vcpu, cpusize, cpumapsize; >>> >>> vcpuid = strtoul(vcpu,&endptr, 10); >>> if (vcpu == endptr) { >>> @@ -3634,12 +3633,13 @@ >>> >>> find_domain(d); >>> >>> - if (libxl_get_physinfo(&ctx,&physinfo) != 0) { >>> - fprintf(stderr, "libxl_get_physinfo failed.\n"); >>> + if ((cpusize = xc_get_max_cpus(ctx.xch)) == 0) { >>> + fprintf(stderr, "xc_get_maxcpus failed.\n"); >>> goto vcpupin_out1; >>> } >> >> You shouldn''t be calling xc functions directly from xl_cmdimpl.c. >> The basic rule is: libxl clients (such as xl) shouldn''t need to call any >> library functions other than libxenlight''s functions. >> You can add a libxl_get_max_cpus function though. > > Maybe we should add libxl_cpumap_alloc_phys which returns a libxl_cpumap > big enough to hold all physical CPUs, there are a few places within > libxl itself which might benefit from this, e.g. libxl_list_cpupool and > libxl_list_vcpu both call xc_get_max_cpus and then use the result as a > parameter to libxl_cpumap_alloc. > > Actually, given that libxl_cpumap is only ever used for PCPUs perhaps > alloc should just always return a suitably sized map and there''s no need > for the size parameter to libxl_cpumap_alloc? Is there any plausible > potential use for a libxl_cpumap of nrVCPU rather than nrPCPU ?Currently there seems to be no demand for cpumasks larger than nrPCPU. Changinf libxl_cpumap_alloc to allocate just the correct size seems appropriate. I think I''ll do this in my planned cpumask rework. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen Gross
2010-Oct-08 08:41 UTC
Re: [Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes
On 10/06/10 15:47, Gianni Tedesco wrote:> On Tue, 2010-10-05 at 14:45 +0100, Juergen Gross wrote: >> diff -r cfce8e755505 -r baee85a24411 tools/python/xen/lowlevel/xl/xl.c >> --- a/tools/python/xen/lowlevel/xl/xl.c Tue Oct 05 14:19:13 2010 +0200 >> +++ b/tools/python/xen/lowlevel/xl/xl.c Tue Oct 05 15:26:24 2010 +0200 >> @@ -208,6 +208,11 @@ >> return -1; >> } >> >> +int attrib__uint64_t_ptr_set(PyObject *v, uint64_t * *pptr) >> +{ >> + return -1; >> +} >> + >> int attrib__libxl_cpumap_set(PyObject *v, libxl_cpumap *pptr) >> { >> return -1; >> @@ -254,6 +259,11 @@ >> } >> >> PyObject *attrib__libxl_cpuid_policy_list_get(libxl_cpuid_policy_list >> *pptr) >> +{ >> + return NULL; >> +} >> + >> +PyObject *attrib__uint64_t_ptr_get(uint64_t * *pptr) >> { >> return NULL; >> } > > Because of using Reference(Uint64) directly in the idl - the python > bindings autogenerate these type-marshalling functions. It''s not quite > clear how these are supposed to be implemented in a generic way! :) > > There ought to be a builtin type for this ala libxl_uuid and other types > to generate correct bindings.Gianni, I suppose I need a builtin for the complete libxl_cpumap type, not only for the uint64_t array due to the size info which is needed to access the array correctly. I''m not sure how to translate this into the correct bindings. I think the cpumap should be translated into a python list. Which methods do I need to include in xc.c? Or would it be okay to add just some minimal dummy functions and put in the functionality if needed? Juergeb -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2010-Oct-08 08:52 UTC
Re: [Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes
On Fri, 2010-10-08 at 09:41 +0100, Juergen Gross wrote:> On 10/06/10 15:47, Gianni Tedesco wrote: > > On Tue, 2010-10-05 at 14:45 +0100, Juergen Gross wrote: > >> diff -r cfce8e755505 -r baee85a24411 tools/python/xen/lowlevel/xl/xl.c > >> --- a/tools/python/xen/lowlevel/xl/xl.c Tue Oct 05 14:19:13 2010 +0200 > >> +++ b/tools/python/xen/lowlevel/xl/xl.c Tue Oct 05 15:26:24 2010 +0200 > >> @@ -208,6 +208,11 @@ > >> return -1; > >> } > >> > >> +int attrib__uint64_t_ptr_set(PyObject *v, uint64_t * *pptr) > >> +{ > >> + return -1; > >> +} > >> + > >> int attrib__libxl_cpumap_set(PyObject *v, libxl_cpumap *pptr) > >> { > >> return -1; > >> @@ -254,6 +259,11 @@ > >> } > >> > >> PyObject *attrib__libxl_cpuid_policy_list_get(libxl_cpuid_policy_list > >> *pptr) > >> +{ > >> + return NULL; > >> +} > >> + > >> +PyObject *attrib__uint64_t_ptr_get(uint64_t * *pptr) > >> { > >> return NULL; > >> } > > > > Because of using Reference(Uint64) directly in the idl - the python > > bindings autogenerate these type-marshalling functions. It''s not quite > > clear how these are supposed to be implemented in a generic way! :) > > > > There ought to be a builtin type for this ala libxl_uuid and other types > > to generate correct bindings. > > Gianni, I suppose I need a builtin for the complete libxl_cpumap type, not > only for the uint64_t array due to the size info which is needed to access > the array correctly.Yes, I think so. There is no way in the IDL to have a pure bitmap type which refers to a different field in the containing structure to get the length, and doing this would likely be unnecessarily complicated.> I''m not sure how to translate this into the correct bindings. I think the > cpumap should be translated into a python list.Yes, I think lists make sense.> Which methods do I need to include in xc.c?I think it will become clear when you try to build it, just follow the build errors ;-)> Or would it be okay to add just some minimal dummy > functions and put in the functionality if needed?Personally, given that you are planning to change the type from uint64_t to bytes I''d be happy if you stubbed them out for uint64_t for now and only implemented properly during the conversion. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Gianni Tedesco
2010-Oct-08 09:21 UTC
Re: [Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes
On Fri, 2010-10-08 at 09:52 +0100, Ian Campbell wrote:> On Fri, 2010-10-08 at 09:41 +0100, Juergen Gross wrote: > > On 10/06/10 15:47, Gianni Tedesco wrote: > > > On Tue, 2010-10-05 at 14:45 +0100, Juergen Gross wrote: > > >> diff -r cfce8e755505 -r baee85a24411 tools/python/xen/lowlevel/xl/xl.c > > >> --- a/tools/python/xen/lowlevel/xl/xl.c Tue Oct 05 14:19:13 2010 +0200 > > >> +++ b/tools/python/xen/lowlevel/xl/xl.c Tue Oct 05 15:26:24 2010 +0200 > > >> @@ -208,6 +208,11 @@ > > >> return -1; > > >> } > > >> > > >> +int attrib__uint64_t_ptr_set(PyObject *v, uint64_t * *pptr) > > >> +{ > > >> + return -1; > > >> +} > > >> + > > >> int attrib__libxl_cpumap_set(PyObject *v, libxl_cpumap *pptr) > > >> { > > >> return -1; > > >> @@ -254,6 +259,11 @@ > > >> } > > >> > > >> PyObject *attrib__libxl_cpuid_policy_list_get(libxl_cpuid_policy_list > > >> *pptr) > > >> +{ > > >> + return NULL; > > >> +} > > >> + > > >> +PyObject *attrib__uint64_t_ptr_get(uint64_t * *pptr) > > >> { > > >> return NULL; > > >> } > > > > > > Because of using Reference(Uint64) directly in the idl - the python > > > bindings autogenerate these type-marshalling functions. It''s not quite > > > clear how these are supposed to be implemented in a generic way! :) > > > > > > There ought to be a builtin type for this ala libxl_uuid and other types > > > to generate correct bindings. > > > > Gianni, I suppose I need a builtin for the complete libxl_cpumap type, not > > only for the uint64_t array due to the size info which is needed to access > > the array correctly.Yes exactly, creating a full struct as you have done is "the right way to do it"(tm). See detailed comments below.> Yes, I think so. > > There is no way in the IDL to have a pure bitmap type which refers to a > different field in the containing structure to get the length, and doing > this would likely be unnecessarily complicated. > > > I''m not sure how to translate this into the correct bindings. I think the > > cpumap should be translated into a python list. > > Yes, I think lists make sense. > > > Which methods do I need to include in xc.c? > > I think it will become clear when you try to build it, just follow the > build errors ;-) > > > Or would it be okay to add just some minimal dummy > > functions and put in the functionality if needed?Yes exactly as Ian says. You will notice plenty of similar stubbed out and unimplemented functions in the python bindings that we can do such nice things with later. If you would like to flesh out the cpupool stuff at the same time as adding it then that would be much appreciated but given how incomplete the binding is we can''t say it''s ''mandatory'' and keep a straight face.> Personally, given that you are planning to change the type from uint64_t > to bytes I''d be happy if you stubbed them out for uint64_t for now and > only implemented properly during the conversion.Yeha on closer inspection, this is all kind of moot from the binding perspective. What needs to happen is for libxl_cpumap to be the builtin type defined in libxl.h (and possibly c&p any destructor functions that were generated in to libxl.c). We don''t need to generate bindings for an object who''s attributes are: (array, length)... Similar to libxl_string_list. In that case the existing attrib__libxl_cpumap_(set|get) for cpupoolinfo can do all of the necessary work of converting to and from python lists and no patch is required to tools/python/.../xl.c. But yes, no point doing an non-dummy implementation of that if it''s only going to change before the rest of the binding is actually written! :) Gianni _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
This is the next version of my patches to support cpupools in xl/libxl.
For full functionality it is necessary to change cpumask handling for cpupools
in libxc (patch 1). Patch 2 adds the full cpupool support in xl.
Patch 3 adds an example configuration file for xm/xl pool-create.
Changes since last version: requests of Ian Campbell, Gianni Tedesco, Stefano
Stabellini
18 files changed, 1018 insertions(+), 237 deletions(-)
tools/examples/README | 1
tools/examples/cpupool | 17 +
tools/libxc/xc_cpupool.c | 118 +++++---
tools/libxc/xc_misc.c | 14 +
tools/libxc/xenctrl.h | 26 -
tools/libxl/libxl.c | 252 ++++++++++++++++--
tools/libxl/libxl.h | 21 +
tools/libxl/libxl.idl | 12
tools/libxl/libxl_internal.h | 2
tools/libxl/libxl_utils.c | 98 ++++++-
tools/libxl/libxl_utils.h | 10
tools/libxl/libxltypes.py | 5
tools/libxl/libxlu_cfg_l.c | 30 --
tools/libxl/libxlu_cfg_l.h | 18 -
tools/libxl/xl.h | 6
tools/libxl/xl_cmdimpl.c | 494 +++++++++++++++++++++++++++++++++++--
tools/libxl/xl_cmdtable.c | 35 ++
tools/python/xen/lowlevel/xc/xc.c | 96 ++-----
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Juergen Gross
2010-Oct-08 11:23 UTC
[Xen-devel] [PATCH 1 of 3] Support arbitrary numbers of physical cpus for cpupools in tools
To be able to support arbitrary numbers of physical cpus it was necessary to include the size of cpumaps in the xc-interfaces for cpu pools. These were: definition of xc_cpupoolinfo_t xc_cpupool_getinfo() xc_cpupool_freeinfo() xc_cpupool_getinfo() and xc_cpupool_freeinfo() are changed to allocate the needed buffer and return it. Signed-off-by: juergen.gross@ts.fujitsu.com 8 files changed, 182 insertions(+), 151 deletions(-) tools/libxc/xc_cpupool.c | 118 ++++++++++++++++++++++--------------- tools/libxc/xc_misc.c | 14 ++++ tools/libxc/xenctrl.h | 26 ++++---- tools/libxl/libxl.c | 49 +++++++-------- tools/libxl/libxl.h | 3 tools/libxl/libxl_utils.c | 5 + tools/libxl/xl_cmdimpl.c | 22 +++--- tools/python/xen/lowlevel/xc/xc.c | 96 ++++++++++++------------------ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen Gross
2010-Oct-08 11:23 UTC
[Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes
Support of cpu pools in xl: library functions xl pool-create xl pool-list xl pool-destroy xl pool-cpu-add xl pool-cpu-remove xl pool-migrate Renamed all cpu pool related names to *cpupool* Signed-off-by: juergen.gross@ts.fujitsu.com 12 files changed, 818 insertions(+), 86 deletions(-) tools/libxl/libxl.c | 203 +++++++++++++++++- tools/libxl/libxl.h | 18 + tools/libxl/libxl.idl | 12 - tools/libxl/libxl_internal.h | 2 tools/libxl/libxl_utils.c | 93 +++++++- tools/libxl/libxl_utils.h | 10 tools/libxl/libxltypes.py | 5 tools/libxl/libxlu_cfg_l.c | 30 -- tools/libxl/libxlu_cfg_l.h | 18 - tools/libxl/xl.h | 6 tools/libxl/xl_cmdimpl.c | 472 ++++++++++++++++++++++++++++++++++++++++-- tools/libxl/xl_cmdtable.c | 35 +++ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen Gross
2010-Oct-08 11:23 UTC
[Xen-devel] [PATCH 3 of 3] add example cpupool config file
Adds an example configuration file for xm/xl pool-create Signed-off-by: juergen.gross@ts.fujitsu.com 2 files changed, 18 insertions(+) tools/examples/README | 1 + tools/examples/cpupool | 17 +++++++++++++++++ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2010-Oct-12 09:51 UTC
Re: [Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes
Juergen Gross writes ("[Xen-devel] [PATCH 2 of 3] support of cpupools in
xl: commands and library changes"):> tools/libxl/libxlu_cfg_l.c | 30 --
> tools/libxl/libxlu_cfg_l.h | 18 -
I see you reran flex. That''s not wrong, but we shouldn''t
change these
files needlessly, and you didn''t make any changes to the .l source
file, so when we apply this patch we should drop the changes to
*_l.[ch].
> Renamed all cpu pool related names to *cpupool*
Is that really true in this patch ? The function names and subcommand
names in xl are still all "pool-*" and "pool_*".
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2010-Oct-12 09:56 UTC
Re: [Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes
On Fri, 2010-10-08 at 12:23 +0100, Juergen Gross wrote:
You need a destructor for the libxl_cpumap type, else you will leak the
->map.
Also you don''t need to explicitly specific destructor_fn for
libxl_cpupoolinfo.
Something like the following. (hint: you can usually spot this stuff by
taking a look at the diff of the generated code in
tools/libxl/_libxl_types.[ch]).
Ian.
diff -r 11f243c2d8be tools/libxl/libxl.h
--- a/tools/libxl/libxl.h Fri Oct 08 13:22:37 2010 +0200
+++ b/tools/libxl/libxl.h Tue Oct 12 10:55:13 2010 +0100
@@ -147,6 +147,7 @@ typedef struct {
uint32_t size; /* number of bytes in map */
uint64_t *map;
} libxl_cpumap;
+void libxl_cpumap_destroy(libxl_cpumap *map);
typedef enum {
XENFV = 1,
diff -r 11f243c2d8be tools/libxl/libxl.idl
--- a/tools/libxl/libxl.idl Fri Oct 08 13:22:37 2010 +0200
+++ b/tools/libxl/libxl.idl Tue Oct 12 10:55:13 2010 +0100
@@ -6,7 +6,7 @@ libxl_ctx = Builtin("ctx")
libxl_ctx = Builtin("ctx")
libxl_uuid = Builtin("uuid")
libxl_mac = Builtin("mac")
-libxl_cpumap = Builtin("cpumap")
+libxl_cpumap = Builtin("cpumap",
destructor_fn="libxl_cpumap_destroy", passby=PASS_BY_REFERENCE)
libxl_qemu_machine_type = Number("qemu_machine_type",
namespace="libxl_")
libxl_console_consback = Number("console_consback",
namespace="libxl_")
libxl_console_constype = Number("console_constype",
namespace="libxl_")
@@ -49,7 +49,7 @@ libxl_cpupoolinfo = Struct("cpupoolinfo"
("sched_id", uint32),
("n_dom", uint32),
("cpumap", libxl_cpumap)
- ], destructor_fn="libxl_cpupoolinfo_destroy")
+ ])
libxl_vminfo = Struct("vminfo", [
("uuid", libxl_uuid),
diff -r 11f243c2d8be tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c Fri Oct 08 13:22:37 2010 +0200
+++ b/tools/libxl/libxl_utils.c Tue Oct 12 10:55:13 2010 +0100
@@ -720,6 +720,11 @@ int libxl_cpumap_alloc(libxl_cpumap *cpu
return 0;
}
+void libxl_cpumap_destroy(libxl_cpumap *map)
+{
+ free(map->map);
+}
+
int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu)
{
if (cpu >= cpumap->size * 8)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Juergen Gross
2010-Oct-12 09:56 UTC
Re: [Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes
On 10/12/10 11:51, Ian Jackson wrote:> Juergen Gross writes ("[Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes"): >> tools/libxl/libxlu_cfg_l.c | 30 -- >> tools/libxl/libxlu_cfg_l.h | 18 - > > I see you reran flex. That''s not wrong, but we shouldn''t change these > files needlessly, and you didn''t make any changes to the .l source > file, so when we apply this patch we should drop the changes to > *_l.[ch].I excluded these changes once before and was told they should be included... I didn''t call flex manually, this was done by make.> >> Renamed all cpu pool related names to *cpupool* > > Is that really true in this patch ? The function names and subcommand > names in xl are still all "pool-*" and "pool_*".There was no response to the question whether to change the sub-command names or not. And I think the sub-command functions should reflect the names. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2010-Oct-12 09:59 UTC
Re: [Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes
On Tue, 2010-10-12 at 10:51 +0100, Ian Jackson wrote:> Juergen Gross writes ("[Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes"): > > tools/libxl/libxlu_cfg_l.c | 30 -- > > tools/libxl/libxlu_cfg_l.h | 18 - > > I see you reran flex. That''s not wrong, but we shouldn''t change these > files needlessly, and you didn''t make any changes to the .l source > file, so when we apply this patch we should drop the changes to > *_l.[ch]. > > > Renamed all cpu pool related names to *cpupool* > > Is that really true in this patch ? The function names and subcommand > names in xl are still all "pool-*" and "pool_*".The subcommands names are the xm names, which I thought we needed to keep for compatibility. We could add both cpupool- and pool- variants and deprecate the later. Or perhaps these commands are not widely used (at least from scripts and whatnot) and we can just change the name. See <4CAB2CE5.1070208@ts.fujitsu.com> and <1286371053.23155.12762.camel@zakaz.uk.xensource.com> for some previous discussion. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen Gross
2010-Oct-12 10:43 UTC
Re: [Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes
On 10/12/10 11:59, Ian Campbell wrote:> On Tue, 2010-10-12 at 10:51 +0100, Ian Jackson wrote: >> Juergen Gross writes ("[Xen-devel] [PATCH 2 of 3] support of cpupools in xl: commands and library changes"): >>> tools/libxl/libxlu_cfg_l.c | 30 -- >>> tools/libxl/libxlu_cfg_l.h | 18 - >> >> I see you reran flex. That''s not wrong, but we shouldn''t change these >> files needlessly, and you didn''t make any changes to the .l source >> file, so when we apply this patch we should drop the changes to >> *_l.[ch]. >> >>> Renamed all cpu pool related names to *cpupool* >> >> Is that really true in this patch ? The function names and subcommand >> names in xl are still all "pool-*" and "pool_*". > > The subcommands names are the xm names, which I thought we needed to > keep for compatibility. > > We could add both cpupool- and pool- variants and deprecate the later. > Or perhaps these commands are not widely used (at least from scripts and > whatnot) and we can just change the name.I have no problems changing the names to cpupool-*. Do you think we should change the names for xm, too? This move should be ack''ed by Novell, as they have included the cpupool stuff in SLES11 SP1. I don''t know if there are other users than Fujitsu (and we could change quite easily). An option would be to support both variants in xm and only cpupool-* in xl. CC-ing Jan. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel