[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH]libxl: allow to set more than 31 vcpus



On Fri, 2012-05-11 at 12:20 +0100, Ian Jackson wrote:
> Zhang, Yang Z writes ("RE: [Xen-devel] [PATCH]libxl: allow to set more than 
> 31 vcpus"):
> > Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]:
> > > This error handling should really go away.  Would you be able to
> > > provide a patch to make libxl_cpumap_alloc use libxl__zalloc(NULL, ) ?
> > > That never fails, so that would also mean libxl_cpumap_alloc can't
> > > fail.
> > 
> > I don't think so. Libxl_cpumap_alloc() also returned error when
> > max_cpus equal zero. So the error handling cannot be avoid even
> > using libxl__zalloc.
> 
> Hmm.  Can it not be made to either abort or succeed in this case ?

max_cpus == 0 means xc_physinfo failed, which is either a memory
allocation failure (bounce buffering) or a pretty serious error
(toolstack/hypervisor mismatch which is logged or perhaps an
XSM/privilege type thing) from which we are unlikely to recover.

I'd say that a hard failure would be acceptable here.

Ian.

> 
> > > > diff -r c6bde42c8845 -r b1229c220984 tools/libxl/libxl_dom.c
> > > > --- a/tools/libxl/libxl_dom.c   Thu Apr 12 14:01:27 2012 +0100
> > > > +++ b/tools/libxl/libxl_dom.c   Fri May 04 10:47:00 2012 +0800
> > > > @@ -146,7 +146,8 @@ int libxl__build_post(libxl__gc *gc, uin
> > > >      ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
> > > >      for (i = 0; i < info->max_vcpus; i++) {
> > > >          ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", 
> > > > i);
> > > > -        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus 
> > > > & (1
> > > << i)))
> > > > +        ents[12+(i*2)+1] = (i && info->avail_vcpus.size
> > > > +
> > > && !libxl_cpumap_test(&info->avail_vcpus, i))
> > > >                              ? "offline" : "online";
> > > 
> > > If libxl_cpumap_test returned 0 if cpumap==NULL then this would be
> > > simpler.
> > 
> > Sorry. What your mean for this?
> 
> I mean that if you changed libxl_cpumap_test to tolerate a NULL cpumap
> and simply return false, then the caller wouldn't have to check for
> it.  But you may prefer to keep it the current way.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.