Re: [Xen-devel] [PATCH] libxl: add libxl__is_driver_domain function

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Dec 14, 2017 at 04:14:12PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov <oleksandr_grytsov@xxxxxxxx>
> 
> We have following arm-based setup:
> 
> - Dom0 with xen and xen tools;
> - Dom1 with device backends (but it is not the driver domain);

What is your definition of a "driver domain"? What does it do in this
case?

I seem to have seen people use this term in different contexts to mean
slightly different things. I need to figure out what you actually mean
first.

> - Dom2 with device frontend;
> 
> On Dom2 destroying we have timeout error. Because xl treats our
> Dom1 as driver domain and waits for backend path to be cleared
> by the driver domain which is not our case.
> 
> According to libxl__domain_make in case of driver domain it has
> "libxl" xen store entry:
> 
>     if (libxl_defbool_val(info->driver_domain)) {
>         /*
>          * Create a local "libxl" directory for each guest, since we might 
> want
>          * to use libxl from inside the guest
>          */
>         libxl__xs_mknod(gc, t, GCSPRINTF("%s/libxl", dom_path), rwperm,
>                         ARRAY_SIZE(rwperm));
> 
> This patch introduces libxl__is_driver_domain which determines the driver
> domain by checking if "libxl" entry is present and uses this function on
> device destroy to check by whom domain path should be cleaned up (libxl
> or the driver domain).
> 
> Oleksandr Grytsov (1):
>   libxl: add libxl__is_driver_domain function
> 
>  tools/libxl/libxl_device.c   | 17 ++++++++++-------
>  tools/libxl/libxl_internal.c | 16 ++++++++++++++++
>  tools/libxl/libxl_internal.h |  4 ++++
>  3 files changed, 30 insertions(+), 7 deletions(-)
> 
> -- 
> 2.7.4
> 

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