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;
}