Re: [Xen-devel] [PATCH] Fix cpumap setting before passing to XEN

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Apr 28, 2016 at 06:02:54PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH] Fix cpumap setting before passing to 
> XEN"):
> > So what is the conclusion of this discussion so far? I admit I'm a bit
> > lost here.
> 
> Undoubtedly:
> 
> * That "xm ..." generates the reported error is definitely a bug.
> 
> * "xm" exists only in versions of Xen now no longer supported
>   upstream.
> 
> * Applying the proposed patch to libxc in upstream supported versions
>   of Xen will not fix "xm" for users like Zhenzhong Duan.

Wait, how will it not? It will continue without erroring out.
> 
> 
> There are two possible views about the nature of the bug:
> 
> 1. It is xm's fault for passing an invalid cpumap.
> 
> 2. It is python xc's fault for failing to tolerate a cpumap with
>    bits set which do not correspond to actual cpus.
> 
> In the case 1., the xm python code needs to be changed.  But there is
> nothing for upstream to do because none of our supported trees contain
> this code any more.
> 
> In the case 2., the in-tree python xc code should be changed.
> 
> 
> I am somewhat reluctant to go down the path implied by case 2, because
> we don't know what collateral damage there may be.  OTOH the proposed
> patch is one which tolerates a wider range of inputs, which is fairly
> safe.
> 
> I think that the behaviour of libxl (which has to provide a C API,
> rather than a python one) is a poor guide to the best behaviour for
> python xc.
> 
> 
> So I still don't have a clear view about whether the patch should be
> applied.  (I think it clearly shouldn't be backported.)

I concur on backporting - but I think having it upstream will save the
folks who bind to the Python libxc code and eventually will hit this.

> 
> Ian.

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