Re: [libvirt] [Xen-devel] [PATCH] Convert libxl driver to Xen 4.2

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.