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;
> }
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list