Tuesday 27 of November 2012 10:51:30, Ian Campbell:
On Mon, 2012-11-26 at 22:28 +0000, Jim Fehlig wrote:
> @@ -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.
You are right that this check is probably unnecessary. While working on some parts of this
patch I
merely tried to update original patch by Daniel De Graaf and wasn't removing any code
I didn't understand.
Anyway, I was inspired by commit e1e1e98cacd8 at Xen git and related patch message [0].
[0]
http://lists.xen.org/archives/html/xen-devel/2012-06/msg01667.html
> */
> - 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;
> }