ARM folks: Please be rather more careful when exposing hypervisor internals to arbitrary user input. Being domain_create, the fallout is unlikely to be an security issue if it had gotten into a release, but Xen will definitely have an unhappy time with unexpected scheduler state.
George/Nick: The Golang bindings seem pre-existingly broken. I get the following spew which is unrelated to this change: ./helpers.gen.go:800[/tmp/go-build762104750/_/local/xen.git/tools/golang/xenlight/_obj/helpers.gen.cgo1.go:1320]: cannot use _Ctype_ulong(numVcpus) * _Cconst_sizeof_libxl_sched_params (type _Ctype_ulong) as type _Ctype_size_t in argument to _Cfunc__CMalloc ./helpers.gen.go:1292[/tmp/go-build762104750/_/local/xen.git/tools/golang/xenlight/_obj/helpers.gen.cgo1.go:1960]: cannot use _Ctype_ulong(numVcpuHardAffinity) * _Cconst_sizeof_libxl_bitmap (type _Ctype_ulong) as type _Ctype_size_t in argument to _Cfunc__CMalloc ./helpers.gen.go:1302[/tmp/go-build762104750/_/local/xen.git/tools/golang/xenlight/_obj/helpers.gen.cgo1.go:1970]: cannot use _Ctype_ulong(numVcpuSoftAffinity) * _Cconst_sizeof_libxl_bitmap (type _Ctype_ulong) as type _Ctype_size_t in argument to _Cfunc__CMalloc ./helpers.gen.go:1336[/tmp/go-build762104750/_/local/xen.git/tools/golang/xenlight/_obj/helpers.gen.cgo1.go:2008]: cannot use _Ctype_ulong(numVnumaNodes) * _Cconst_sizeof_libxl_vnode_info (type _Ctype_ulong) as type _Ctype_size_t in argument to _Cfunc__CMalloc ./helpers.gen.go:1379[/tmp/go-build762104750/_/local/xen.git/tools/golang/xenlight/_obj/helpers.gen.cgo1.go:2063]: cannot use _Ctype_ulong(numIoports) * _Cconst_sizeof_libxl_ioport_range (type _Ctype_ulong) as type _Ctype_size_t in argument to _Cfunc__CMalloc ./helpers.gen.go:1397[/tmp/go-build762104750/_/local/xen.git/tools/golang/xenlight/_obj/helpers.gen.cgo1.go:2081]: cannot use _Ctype_ulong(numIomem) * _Cconst_sizeof_libxl_iomem_range (type _Ctype_ulong) as type _Ctype_size_t in argument to _Cfunc__CMalloc ./helpers.gen.go:2518[/tmp/go-build762104750/_/local/xen.git/tools/golang/xenlight/_obj/helpers.gen.cgo1.go:3919]: cannot use _Ctype_ulong(numConnectors) * _Cconst_sizeof_libxl_connector_param (type _Ctype_ulong) as type _Ctype_size_t in argument to _Cfunc__CMalloc ./helpers.gen.go:2676[/tmp/go-build762104750/_/local/xen.git/tools/golang/xenlight/_obj/helpers.gen.cgo1.go:4182]: cannot use _Ctype_ulong(numVsndStreams) * _Cconst_sizeof_libxl_vsnd_stream (type _Ctype_ulong) as type _Ctype_size_t in argument to _Cfunc__CMalloc ./helpers.gen.go:2741[/tmp/go-build762104750/_/local/xen.git/tools/golang/xenlight/_obj/helpers.gen.cgo1.go:4288]: cannot use _Ctype_ulong(numVsndPcms) * _Cconst_sizeof_libxl_vsnd_pcm (type _Ctype_ulong) as type _Ctype_size_t in argument to _Cfunc__CMalloc ./helpers.gen.go:2930[/tmp/go-build762104750/_/local/xen.git/tools/golang/xenlight/_obj/helpers.gen.cgo1.go:4540]: cannot use _Ctype_ulong(numDisks) * _Cconst_sizeof_libxl_device_disk (type _Ctype_ulong) as type _Ctype_size_t in argument to _Cfunc__CMalloc ./helpers.gen.go:2930[/tmp/go-build762104750/_/local/xen.git/tools/golang/xenlight/_obj/helpers.gen.cgo1.go:4540]: too many errors but this is where my knowledge ends. Needless to say, the golang bindings haven't been regenerated with this change in place. Roger/Stefano/Doug: Given the golang breakage, we are presuamably lacking golang from any of the CI containers. Andrew Cooper (2): xen/cpupool: Reject attempts to add a domain to CPUPOOLID_NONE tools/ocaml: Fix stubs the introduction of domain_create.cpupool_id tools/ocaml/libs/xc/xenctrl.ml | 1 + tools/ocaml/libs/xc/xenctrl.mli | 1 + tools/ocaml/libs/xc/xenctrl_stubs.c | 8 +++++++- xen/common/sched/cpupool.c | 2 -- 4 files changed, 9 insertions(+), 3 deletions(-) -- 2.11.0
