Re: vnuma_nodes missing pnode 0

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Mon, Nov 14, 2022 at 08:53:17AM -0700, Jim Fehlig wrote:
> On 11/14/22 01:18, Jan Beulich wrote:
> > On 14.11.2022 07:43, Henry Wang wrote:
> > > Sorry, missed Anthony (The toolstack maintainer). Also added him
> > > to this thread.
> > 
> > Indeed there's nothing x86-ish in here, it's all about data representation.
> > It merely happens to be (for now) x86-specific data which is being dealt
> > with.
> > 
> > Internally I indicated to Jim that the way the code presently is generated
> > it looks to me as if 0 was simply taken as the default for "pnode". What I
> > don't know at all is whether the concept of any kind of default is actually
> > valid in json representation of guest configs.
> 
> 0 is definitely ignored in the generated libxl_vnode_info_gen_json()
> function, which essentially has
> 
> if (p->pnode)
>   format-json
> 
> I took a quick peek at the generator, but being totally unfamiliar could not
> spot a fix. I'm also not sure how such a fix could be detected for testing
> purposes by libxl users like libvirt. I.e. how to detect a libxl that emits
> `"pnode:" 0` in the json representation of libxl_domain_config object and
> one that does not.

Well, the missing "pnode: 0' in json isn't exactly a bug, it's been done
on purpose, see 
https://xenbits.xen.org/gitweb/?p=xen.git;h=731233d64f6a7602c1ca297f7b67ec254

When the JSON is been reloaded into it's original struct,
libxl_vnode_info, pnode will have the expected value, that is 0, because
libxl_vnode_info_init() would have reset this field to 0.

I don't think it's possible to change the generator to just have it
generate '"pnode": 0', as if we make a change, it would have to be for
all unsigned it, I think.

Is it actually wanted to have all those in json, or is it just a case of
looking like there's missing part?

Also, I don't know if any part of libxl rely of this behavior, that is
where default values are omitted from json output.

Thanks,

-- 
Anthony PERARD