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