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

Re: [Xen-devel] [XEN PATCH for-4.13 v1] Reset iomem's gfn to LIBXL_INVALID_GFN on reboot



On Tue, Oct 22, 2019 at 9:14 PM Julien Grall <julien.grall@xxxxxxx> wrote:
>
> Hi Oleksandr,
>
> Apologies for the late answer.
>
> On 16/10/2019 14:09, Oleksandr Grytsov wrote:
> > On Mon, Oct 14, 2019 at 12:28 PM Julien Grall <julien.grall@xxxxxxx> wrote:
> > Thanks to point me out for this old thread. I completely forgot about it
> > (I haven't worked with xen since long time). I've performed additional
> > investigation
> > and found the root cause of the issue. It doesn't relate to iomem GFN 
> > directly.
> > The problem is in type from json parsing at place where libxl creates array 
> > of
> > struct.
> >
> > For example, libxl_domain_config_from_json calls libxl_domain_config_init
> > which initializes all child structures and arrays. But then when libxl 
> > parses
> > json and creates the array of structure, it doesn't initialize array 
> > elements
> > properly (see libxl__domain_build_info_parse_json iomem parsing):
> >
> > p->num_iomem = x->u.array->count;
> > p->iomem = libxl__calloc(NOGC, p->num_iomem, sizeof(*p->iomem));
> > if (!p->iomem && p->num_iomem != 0) {
> >      rc = -1;
> >      goto out;
> > }
> > for (i=0; (t=libxl__json_array_get(x,i)); i++) {
> >      rc = libxl__iomem_range_parse_json(gc, t, &p->iomem[i]);
> >      if (rc)
> >         goto out;
> > }
> >
> > libxl creates array element with calloc function, so all element
> > fields are initialized
> > with zero values. Even some of them have default value different from zero.
> > For these purpose dedicated init function should be called for each element.
> > Above example should be:
> >
> > for (i=0; (t=libxl__json_array_get(x,i)); i++) {
> >      libxl_iomem_range_init(&p->iomem[i]);
> >      rc = libxl__iomem_range_parse_json(gc, t, &p->iomem[i]);
> >      if (rc)
> >         goto out;
> > }
>
> Not initializing the values is fine as long as the JSON describes all the 
> fields
> of the structure.
>
> The key point here is the GFN is not described in the JSON (see
> libxl_iomem_range_gen_json) if it is equal to LIBXL_INVALID_GFN. As the field 
> is
> not described, it will be defaulted to 0.
>

Yes. So, either  ..._gen_json should generate entries for default
values or ..._parse_json
should set missing entries to its default values. Second solution looks more
correct.

> >
> > I've changes gentypes.py as following:
> >
> > diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
> > index 88e5c5f30e..92e28be469 100644
> > --- a/tools/libxl/gentypes.py
> > +++ b/tools/libxl/gentypes.py
> > @@ -454,6 +454,8 @@ def libxl_C_type_parse_json(ty, w, v, indent = "
> >   ", parent = None, discrimina
> >           s += "        goto out;\n"
> >           s += "    }\n"
> >           s += "    for (i=0; (t=libxl__json_array_get(x,i)); i++) {\n"
> > +        if ty.elem_type.init_fn is not None and
> > ty.elem_type.autogenerate_init_fn:
>
> My knowledge of libxl is quite limited. But I don't think this is correct, you
> want to call init_fn whether this has been autogenerated or not.
>
> > +            s += indent + "    "+"%s_init(&%s[i]);\n" %
> > (ty.elem_type.typename, v)
>
> Looking at the other usage (like _libxl_C_type_init), init_fn is called with
>
>              s += "%s(%s);\n" % (ty.init_fn, ty.pass_arg(v, parent is None))
>
> I am also not entirely sure whether we should also cater the ty.init_val != 
> None
> as well here.
>
> >           s += libxl_C_type_parse_json(ty.elem_type, "t", v+"[i]",
> >                                        indent + "    ", parent)
> >           s += "    }\n"
> >
> > I'm not sure is it right and complete fix.
> >
> > Ian, could you review?
> >
> > If the fix is ok, I will submit the patch.
>
> IHMO, the idea is there. The code may need some modifications (see above).
> Please post a patch so we can go forward in the process to review it.

Thanks. I will post the separate path.

>
> Cheers,
>
> --
> Julien Grall



-- 
Best Regards,
Oleksandr Grytsov.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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