[PATCH] libxl: add libxl__is_driver_domain function

[PATCH] libxl: add libxl__is_driver_domain function

[Oleksandr Grytsov]

From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>

We have following arm-based setup:

- Dom0 with xen and xen tools;
- Dom1 with device backends (but it is not the driver domain);
- 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH] libxl: add libxl__is_driver_domain function

[Oleksandr Grytsov]

From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>

libxl__is_driver_domain determines the driver domain by
presence of libxl entry in the domain xen store. Use
this function on device destroy to properly manage cleanup
in case backends are located on domain with non zero id.

Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
---
 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(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index f84422e..08a33e2 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -732,7 +732,7 @@ int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
                 libxl__xs_path_cleanup(gc, t, fe_path);
             libxl__xs_path_cleanup(gc, t, libxl_path);
         }
-        if (dev->backend_domid == domid && !libxl_only) {
+        if (!libxl__is_driver_domain(gc, dev->backend_domid) && !libxl_only) {
             /*
              * The driver domain is in charge of removing what it can
              * from the backend path.
@@ -1110,16 +1110,19 @@ static void device_hotplug(libxl__egc *egc, libxl__ao_device *aodev)
         LOGD(ERROR, aodev->dev->domid, "Failed to get domid");
         goto out;
     }
-    if (aodev->dev->backend_domid != domid) {
+
+    if (aodev->dev->backend_domid != domid &&
+        aodev->action != LIBXL__DEVICE_ACTION_REMOVE) {
+        LOG(DEBUG, "Not a remove, not executing hotplug scripts");
+        goto out;
+    }
+
+    if (libxl__is_driver_domain(gc, aodev->dev->backend_domid) &&
+        aodev->action == LIBXL__DEVICE_ACTION_REMOVE) {
         LOGD(DEBUG, aodev->dev->domid,
              "Backend domid %d, domid %d, assuming driver domains",
              aodev->dev->backend_domid, domid);
 
-        if (aodev->action != LIBXL__DEVICE_ACTION_REMOVE) {
-            LOG(DEBUG, "Not a remove, not executing hotplug scripts");
-            goto out;
-        }
-
         aodev->xswait.ao = ao;
         aodev->xswait.what = "removal of backend path";
         aodev->xswait.path = be_path;
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index f492dae..a65bc58 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -575,6 +575,22 @@ void libxl__update_domain_configuration(libxl__gc *gc,
     dst->b_info.video_memkb = src->b_info.video_memkb;
 }
 
+bool libxl__is_driver_domain(libxl__gc *gc, uint32_t domid)
+{
+    const char *val;
+    int rc;
+
+    char *dom_path = libxl__xs_get_dompath(gc, domid);
+
+    if (!dom_path) return false;
+
+    rc = libxl__xs_read_checked(gc, XBT_NULL,
+                                GCSPRINTF("%s/libxl", dom_path), &val);
+    if (rc) return false;
+
+    return val != NULL;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7fab561..f566d81 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4414,6 +4414,10 @@ void* libxl__device_list(libxl__gc *gc, const struct libxl_device_type *dt,
                          uint32_t domid, int *num);
 void libxl__device_list_free(const struct libxl_device_type *dt,
                              void *list, int num);
+
+/* Check if domain is driver domain */
+_hidden bool libxl__is_driver_domain(libxl__gc *gc, uint32_t domid);
+
 #endif
 
 /*
-- 
2.7.4


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

Re: [PATCH] libxl: add libxl__is_driver_domain function

[Oleksandr Grytsov]

[-- Attachment #1.1: Type: text/plain, Size: 1727 bytes --]

On Thu, Dec 14, 2017 at 4:14 PM, Oleksandr Grytsov <al1img@gmail.com> wrote:

> From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
>
> We have following arm-based setup:
>
> - Dom0 with xen and xen tools;
> - Dom1 with device backends (but it is not the driver domain);
> - 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
>
>

ping and update

There is run_hotplug_scripts parameter in xl.cfg. I guess it is related to
this issue. But looking
through the code I see that this parameter is not used. Could anyone
provide more info about
this parameter?

-- 
Best Regards,
Oleksandr Grytsov.

[-- Attachment #1.2: Type: text/html, Size: 2641 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: [PATCH] libxl: add libxl__is_driver_domain function

[Oleksandr Grytsov]

[-- Attachment #1.1: Type: text/plain, Size: 1916 bytes --]

On Tue, Jan 9, 2018 at 1:34 PM, Oleksandr Grytsov <al1img@gmail.com> wrote:

> On Thu, Dec 14, 2017 at 4:14 PM, Oleksandr Grytsov <al1img@gmail.com>
> wrote:
>
>> From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
>>
>> We have following arm-based setup:
>>
>> - Dom0 with xen and xen tools;
>> - Dom1 with device backends (but it is not the driver domain);
>> - 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
>>
>>
>
> ping and update
>
> There is run_hotplug_scripts parameter in xl.cfg. I guess it is related to
> this issue. But looking
> through the code I see that this parameter is not used. Could anyone
> provide more info about
> this parameter?
>
> --
> Best Regards,
> Oleksandr Grytsov.
>

ping

-- 
Best Regards,
Oleksandr Grytsov.

[-- Attachment #1.2: Type: text/html, Size: 3431 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: [PATCH] libxl: add libxl__is_driver_domain function

[Wei Liu]

On Thu, Dec 14, 2017 at 04:14:12PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
> 
> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH] libxl: add libxl__is_driver_domain function

[Oleksandr Grytsov]

[-- Attachment #1.1: Type: text/plain, Size: 2241 bytes --]

On Tue, Feb 6, 2018 at 2:36 PM, Wei Liu <wei.liu2@citrix.com> wrote:

> On Thu, Dec 14, 2017 at 04:14:12PM +0200, Oleksandr Grytsov wrote:
> > From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
> >
> > 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.
>
>
I see in the libxl/xl sources that closing PV devices is done differently
in case backends are in Dom0 and are in other domain. It is called as
driver domain in the sources. So, I don't have clear understanding
what does it mean. In our setup backends are in Dom1 and xl is in Dom0.
And I see that xl dosn't close PV device on domain reboot or shutdown.


> > - 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
> >
>



-- 
Best Regards,
Oleksandr Grytsov.

[-- Attachment #1.2: Type: text/html, Size: 3386 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: [PATCH] libxl: add libxl__is_driver_domain function

[Wei Liu]

On Tue, Feb 06, 2018 at 03:08:45PM +0200, Oleksandr Grytsov wrote:
> On Tue, Feb 6, 2018 at 2:36 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> 
> > On Thu, Dec 14, 2017 at 04:14:12PM +0200, Oleksandr Grytsov wrote:
> > > From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
> > >
> > > 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.
> >
> >
> I see in the libxl/xl sources that closing PV devices is done differently
> in case backends are in Dom0 and are in other domain. It is called as
> driver domain in the sources. So, I don't have clear understanding
> what does it mean. In our setup backends are in Dom1 and xl is in Dom0.
> And I see that xl dosn't close PV device on domain reboot or shutdown.

Do you run xl devd in your backend domain?

Wei.

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

Re: [PATCH] libxl: add libxl__is_driver_domain function

[Oleksandr Grytsov]

[-- Attachment #1.1: Type: text/plain, Size: 1281 bytes --]

On Tue, Feb 13, 2018 at 2:06 PM, Wei Liu <wei.liu2@citrix.com> wrote:

> On Tue, Feb 06, 2018 at 03:08:45PM +0200, Oleksandr Grytsov wrote:
> > On Tue, Feb 6, 2018 at 2:36 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> >
> > > On Thu, Dec 14, 2017 at 04:14:12PM +0200, Oleksandr Grytsov wrote:
> > > > From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
> > > >
> > > > 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.
> > >
> > >
> > I see in the libxl/xl sources that closing PV devices is done differently
> > in case backends are in Dom0 and are in other domain. It is called as
> > driver domain in the sources. So, I don't have clear understanding
> > what does it mean. In our setup backends are in Dom1 and xl is in Dom0.
> > And I see that xl dosn't close PV device on domain reboot or shutdown.
>
> Do you run xl devd in your backend domain?
>
> Wei.
>

No I don't

-- 
Best Regards,
Oleksandr Grytsov.

[-- Attachment #1.2: Type: text/html, Size: 2156 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: [PATCH] libxl: add libxl__is_driver_domain function

[Wei Liu]

On Tue, Feb 13, 2018 at 03:32:04PM +0200, Oleksandr Grytsov wrote:
> On Tue, Feb 13, 2018 at 2:06 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> 
> > On Tue, Feb 06, 2018 at 03:08:45PM +0200, Oleksandr Grytsov wrote:
> > > On Tue, Feb 6, 2018 at 2:36 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> > >
> > > > On Thu, Dec 14, 2017 at 04:14:12PM +0200, Oleksandr Grytsov wrote:
> > > > > From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
> > > > >
> > > > > 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.
> > > >
> > > >
> > > I see in the libxl/xl sources that closing PV devices is done differently
> > > in case backends are in Dom0 and are in other domain. It is called as
> > > driver domain in the sources. So, I don't have clear understanding
> > > what does it mean. In our setup backends are in Dom1 and xl is in Dom0.
> > > And I see that xl dosn't close PV device on domain reboot or shutdown.
> >
> > Do you run xl devd in your backend domain?
> >
> > Wei.
> >
> 
> No I don't

Can you try that? I think xl devd should clean up the stale entries --
that's how we envisage driver domains to be used.

Wei.

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

Re: [PATCH] libxl: add libxl__is_driver_domain function

[Oleksandr Grytsov]

[-- Attachment #1.1: Type: text/plain, Size: 1730 bytes --]

On Fri, Feb 23, 2018 at 7:44 PM, Wei Liu <wei.liu2@citrix.com> wrote:

> On Tue, Feb 13, 2018 at 03:32:04PM +0200, Oleksandr Grytsov wrote:
> > On Tue, Feb 13, 2018 at 2:06 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> >
> > > On Tue, Feb 06, 2018 at 03:08:45PM +0200, Oleksandr Grytsov wrote:
> > > > On Tue, Feb 6, 2018 at 2:36 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> > > >
> > > > > On Thu, Dec 14, 2017 at 04:14:12PM +0200, Oleksandr Grytsov wrote:
> > > > > > From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
> > > > > >
> > > > > > 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.
> > > > >
> > > > >
> > > > I see in the libxl/xl sources that closing PV devices is done
> differently
> > > > in case backends are in Dom0 and are in other domain. It is called as
> > > > driver domain in the sources. So, I don't have clear understanding
> > > > what does it mean. In our setup backends are in Dom1 and xl is in
> Dom0.
> > > > And I see that xl dosn't close PV device on domain reboot or
> shutdown.
> > >
> > > Do you run xl devd in your backend domain?
> > >
> > > Wei.
> > >
> >
> > No I don't
>
> Can you try that? I think xl devd should clean up the stale entries --
> that's how we envisage driver domains to be used.
>
> Wei.
>

We will check this. Thanks.

-- 
Best Regards,
Oleksandr Grytsov.

[-- Attachment #1.2: Type: text/html, Size: 2855 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

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

[Oleksandr Grytsov]

On Mon, Feb 26, 2018 at 12:14 PM Oleksandr Grytsov <al1img@gmail.com> wrote:
>
> On Fri, Feb 23, 2018 at 7:44 PM, Wei Liu <wei.liu2@citrix.com> wrote:
>>
>> On Tue, Feb 13, 2018 at 03:32:04PM +0200, Oleksandr Grytsov wrote:
>> > On Tue, Feb 13, 2018 at 2:06 PM, Wei Liu <wei.liu2@citrix.com> wrote:
>> >
>> > > On Tue, Feb 06, 2018 at 03:08:45PM +0200, Oleksandr Grytsov wrote:
>> > > > On Tue, Feb 6, 2018 at 2:36 PM, Wei Liu <wei.liu2@citrix.com> wrote:
>> > > >
>> > > > > On Thu, Dec 14, 2017 at 04:14:12PM +0200, Oleksandr Grytsov wrote:
>> > > > > > From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
>> > > > > >
>> > > > > > 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.
>> > > > >
>> > > > >
>> > > > I see in the libxl/xl sources that closing PV devices is done differently
>> > > > in case backends are in Dom0 and are in other domain. It is called as
>> > > > driver domain in the sources. So, I don't have clear understanding
>> > > > what does it mean. In our setup backends are in Dom1 and xl is in Dom0.
>> > > > And I see that xl dosn't close PV device on domain reboot or shutdown.
>> > >
>> > > Do you run xl devd in your backend domain?
>> > >
>> > > Wei.
>> > >
>> >
>> > No I don't
>>
>> Can you try that? I think xl devd should clean up the stale entries --
>> that's how we envisage driver domains to be used.
>>
>> Wei.
>
>
> We will check this. Thanks.
>
> --
> Best Regards,
> Oleksandr Grytsov.


Let me renew this topic.

xl devd cleans up the state entries only for specific devices: VBD, VIF, QDISK.
I wonder, shall xl devd perform cleaning for all other backends in
driver domain as well?


-- 
Best Regards,
Oleksandr Grytsov.

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