On Mon, 2012-11-26 at 22:28 +0000, Jim Fehlig wrote:
@@ -62,6 +63,52 @@ struct guest_arch { static const char *xen_cap_re = "(xen|hvm)-[[:digit:]]+\ \.[[:digit:]]+-(x86_32|x86_64|ia64|powerpc64)(p|be)?"; static regex_t xen_cap_rec;
+/* + * Copied from split_string_into_string_list() in + * $xen-sources/tools/libxl/xl_cmdimpl.c, which is licensed LGPL v2.1. + */
Looks like I am the sole author of that original function (24250:71ecbef5645f xen-unstable.hg). I'd more than likely be happy to relicence under whatever terms would be suitable for libvirt -- what are they? In particular I'd be happy with LGPL v2.1+ if that's what it takes.
+static int +libxlSplitStringIntoStringList(const char *str, + const char *delim, + libxl_string_list *psl) [...]
@@ -393,26 +458,25 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config) int hvm = STREQ(def->os.type, "hvm"); int i;
- /* Currently, libxenlight only supports 32 vcpus per domain. - * cur_vcpus member of struct libxl_domain_build_info is defined - * as an int, but its semantic is a bitmap of online vcpus, so - * only 32 can be represented. + /* + * libxl in Xen 4.2 supports up to 128 vcpus, cur_vcpus was replaced + * by avail_vcpus of type libxl_bitmap
Do you happen to know where the 128 number comes from? I think libxl is mostly agnostic about the size of this bitmap and should just be exposing whatever the hypervisor supports.
*/ - if (def->maxvcpus > 32 || def->vcpus > 32) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("This version of libxenlight only supports 32 " - "vcpus per domain")); + if (def->maxvcpus > LIBXL_MAXVCPUS || def->vcpus > LIBXL_MAXVCPUS) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("This version of libxenlight only supports %u " + "vcpus per domain"), LIBXL_MAXVCPUS); return -1; }