| Message ID | 1450444471-6454-4-git-send-email-jgross@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 18/12/15 13:14, Juergen Gross wrote: > Add libxl_xenstore_domid() to obtain the domain id of the xenstore > domain. > > Signed-off-by: Juergen Gross <jgross@suse.com> What are the expected semantics here? Would you expect it to return domid 0 for a traditional setup, or are you wanting to use it as a "does a xenstored domain exist" test? > --- > tools/libxl/libxl.c | 24 ++++++++++++++++++++++++ > tools/libxl/libxl.h | 11 +++++++++++ > 2 files changed, 35 insertions(+) > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > index 9207621..3bcff59 100644 > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -701,6 +701,30 @@ int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo *info_r, > return 0; > } > > +int libxl_xenstore_domid(libxl_ctx *ctx, uint32_t *domid) > +{ > + xc_dominfo_t info; > + uint32_t last_domid; > + int ret; > + GC_INIT(ctx); > + > + for (last_domid = 0; > + (ret = xc_domain_getinfo(ctx->xch, last_domid, 1, &info)) == 1; > + last_domid = info.domid + 1) Just as a note, this will scale badly with large numbers of domains. A lot of other actions in libxl will as well, so I don't think it warrants changing at this point. At some point, I need to progress my plans to have stats information like this exposed via shared memory rather than hypercall. ~Andrew
On 18/12/15 14:53, Andrew Cooper wrote: > On 18/12/15 13:14, Juergen Gross wrote: >> Add libxl_xenstore_domid() to obtain the domain id of the xenstore >> domain. >> >> Signed-off-by: Juergen Gross <jgross@suse.com> > > What are the expected semantics here? Would you expect it to return > domid 0 for a traditional setup, or are you wanting to use it as a "does > a xenstored domain exist" test? The latter. It will be used in patch 13 to decide which domain to stop via "xl shutdown --all". > >> --- >> tools/libxl/libxl.c | 24 ++++++++++++++++++++++++ >> tools/libxl/libxl.h | 11 +++++++++++ >> 2 files changed, 35 insertions(+) >> >> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c >> index 9207621..3bcff59 100644 >> --- a/tools/libxl/libxl.c >> +++ b/tools/libxl/libxl.c >> @@ -701,6 +701,30 @@ int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo *info_r, >> return 0; >> } >> >> +int libxl_xenstore_domid(libxl_ctx *ctx, uint32_t *domid) >> +{ >> + xc_dominfo_t info; >> + uint32_t last_domid; >> + int ret; >> + GC_INIT(ctx); >> + >> + for (last_domid = 0; >> + (ret = xc_domain_getinfo(ctx->xch, last_domid, 1, &info)) == 1; >> + last_domid = info.domid + 1) > > Just as a note, this will scale badly with large numbers of domains. A > lot of other actions in libxl will as well, so I don't think it warrants > changing at this point. I know. I think it won't really matter, as there are very few scenarios where this information is needed. I even noticed that libxl won't work very well with more than 1024 domains, as libxl_list_domain() has 1024 as fixed upper bound of number of domains (just testing a patch to repair that). Juergen
On Fri, 2015-12-18 at 15:10 +0100, Juergen Gross wrote: > On 18/12/15 14:53, Andrew Cooper wrote: > > On 18/12/15 13:14, Juergen Gross wrote: > > > Add libxl_xenstore_domid() to obtain the domain id of the xenstore > > > domain. > > > > > > Signed-off-by: Juergen Gross <jgross@suse.com> > > > > What are the expected semantics here? Would you expect it to return > > domid 0 for a traditional setup, or are you wanting to use it as a > > "does > > a xenstored domain exist" test? > > The latter. It will be used in patch 13 to decide which domain to > stop via "xl shutdown --all". ITYM "not stop". libxl already has interfaces for getting info about a domain, libxl_domain_info libxl_list_domain etc, it seems like this property should be added to that data rather than introducing a special purpose API to get it. Especially given that xl shutdown already calls libxl_list_domain. I'm unsure if (lib)xl ought to be special casing XS in this way, as opposed to adding a more generic concept such as e.g. permanent domains, which would be true for the xs domain but also for other special domains in the future and could even be controlled by the user or toolstack (I'm thinking you might want to set the flag on a driver domain for example). Ian.
Ian Campbell writes ("Re: [Xen-devel] [PATCH v2 03/13] libxl: provide a function to retrieve the xenstore domain id"):
> On Fri, 2015-12-18 at 15:10 +0100, Juergen Gross wrote:
> > The latter. It will be used in patch 13 to decide which domain to
> > stop via "xl shutdown --all".
>
> ITYM "not stop".
>
> libxl already has interfaces for getting info about a
> domain, libxl_domain_info libxl_list_domain etc, it seems like this
> property should be added to that data rather than introducing a special
> purpose API to get it. Especially given that xl shutdown already calls
> libxl_list_domain.
>
> I'm unsure if (lib)xl ought to be special casing XS in this way, as opposed
> to adding a more generic concept such as e.g. permanent domains, which
> would be true for the xs domain but also for other special domains in the
> future and could even be controlled by the user or toolstack (I'm thinking
> you might want to set the flag on a driver domain for example).
Indeed, I think a more general concept would be sensible. Stub dm
domains are already handled specially I think.
Ian.
On 06/01/16 16:59, Ian Campbell wrote: > On Fri, 2015-12-18 at 15:10 +0100, Juergen Gross wrote: >> On 18/12/15 14:53, Andrew Cooper wrote: >>> On 18/12/15 13:14, Juergen Gross wrote: >>>> Add libxl_xenstore_domid() to obtain the domain id of the xenstore >>>> domain. >>>> >>>> Signed-off-by: Juergen Gross <jgross@suse.com> >>> >>> What are the expected semantics here? Would you expect it to return >>> domid 0 for a traditional setup, or are you wanting to use it as a >>> "does >>> a xenstored domain exist" test? >> >> The latter. It will be used in patch 13 to decide which domain to >> stop via "xl shutdown --all". > > ITYM "not stop". Well, yes, if you select which domains to stop you select which domains are not stopped, too. :-) I don't mind either wording. :-) > libxl already has interfaces for getting info about a > domain, libxl_domain_info libxl_list_domain etc, it seems like this > property should be added to that data rather than introducing a special > purpose API to get it. Especially given that xl shutdown already calls > libxl_list_domain. Okay, I can change it that way. > I'm unsure if (lib)xl ought to be special casing XS in this way, as opposed > to adding a more generic concept such as e.g. permanent domains, which > would be true for the xs domain but also for other special domains in the > future and could even be controlled by the user or toolstack (I'm thinking > you might want to set the flag on a driver domain for example). The xs domain has to be handled separately, as it is needed to run in order to be able to stop other domains in a clean way. In case dom0 reboot will be supported we need two different reboot modes: one with a hypervisor reboot implying all domains will be stopped (including the xs domain), and one without hypervisor reboot implying that all domains not requiring dom0 to be up all time will still be running after dom0 is up again. For stopping all domains before doing a hypervisor reboot, driver domains should be stopped, too, but they should be stopped _after_ all other domains. And even then the xs domain should be still running when the driver domains are being stopped. IMO the generic concept you are asking for should be added in a separate patch handling stopping (and possibly rebooting) driver domains in a clean way. Juergen
On Thu, 2016-01-07 at 06:37 +0100, Juergen Gross wrote: > On 06/01/16 16:59, Ian Campbell wrote: > > On Fri, 2015-12-18 at 15:10 +0100, Juergen Gross wrote: > > > On 18/12/15 14:53, Andrew Cooper wrote: > > > > On 18/12/15 13:14, Juergen Gross wrote: > > > > > Add libxl_xenstore_domid() to obtain the domain id of the > > > > > xenstore > > > > > domain. > > > > > > > > > > Signed-off-by: Juergen Gross <jgross@suse.com> > > > > > > > > What are the expected semantics here? Would you expect it to return > > > > domid 0 for a traditional setup, or are you wanting to use it as a > > > > "does > > > > a xenstored domain exist" test? > > > > > > The latter. It will be used in patch 13 to decide which domain to > > > stop via "xl shutdown --all". > > > > ITYM "not stop". > > Well, yes, if you select which domains to stop you select which domains > are not stopped, too. :-) > > I don't mind either wording. :-) In the sense you meant I think you want "domains". > > libxl already has interfaces for getting info about a > > domain, libxl_domain_info libxl_list_domain etc, it seems like this > > property should be added to that data rather than introducing a special > > purpose API to get it. Especially given that xl shutdown already calls > > libxl_list_domain. > > Okay, I can change it that way. Thanks. > > I'm unsure if (lib)xl ought to be special casing XS in this way, as > > opposed > > to adding a more generic concept such as e.g. permanent domains, which > > would be true for the xs domain but also for other special domains in > > the > > future and could even be controlled by the user or toolstack (I'm > > thinking > > you might want to set the flag on a driver domain for example). > > The xs domain has to be handled separately, as it is needed to run in > order to be able to stop other domains in a clean way. > > In case dom0 reboot will be supported we need two different reboot > modes: one with a hypervisor reboot implying all domains will be > stopped (including the xs domain), and one without hypervisor reboot > implying that all domains not requiring dom0 to be up all time will > still be running after dom0 is up again. > > For stopping all domains before doing a hypervisor reboot, driver > domains should be stopped, too, but they should be stopped _after_ > all other domains. And even then the xs domain should be still > running when the driver domains are being stopped. So what we have is in effect some sort of reboot ordering or priority and a threshold depending on what sort of reboot the host as a whole is undergoing? > IMO the generic concept you are asking for should be added in a > separate patch handling stopping (and possibly rebooting) driver > domains in a clean way. Since libxl has a stable API once we add something we need to continue supporting it, so we cannot (easily/cleanly) switch an xs specific scheme into a generic one later. That argues then for supporting the XS case via the generic mechanism now, even if we don't implement the other cases. > > > Juergen > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On 07/01/16 11:11, Ian Campbell wrote: > On Thu, 2016-01-07 at 06:37 +0100, Juergen Gross wrote: >> On 06/01/16 16:59, Ian Campbell wrote: >>> On Fri, 2015-12-18 at 15:10 +0100, Juergen Gross wrote: >>>> On 18/12/15 14:53, Andrew Cooper wrote: >>>>> On 18/12/15 13:14, Juergen Gross wrote: >>>>>> Add libxl_xenstore_domid() to obtain the domain id of the >>>>>> xenstore >>>>>> domain. >>>>>> >>>>>> Signed-off-by: Juergen Gross <jgross@suse.com> >>>>> >>>>> What are the expected semantics here? Would you expect it to return >>>>> domid 0 for a traditional setup, or are you wanting to use it as a >>>>> "does >>>>> a xenstored domain exist" test? >>>> >>>> The latter. It will be used in patch 13 to decide which domain to >>>> stop via "xl shutdown --all". >>> >>> ITYM "not stop". >> >> Well, yes, if you select which domains to stop you select which domains >> are not stopped, too. :-) >> >> I don't mind either wording. :-) > > In the sense you meant I think you want "domains". Indeed. >>> I'm unsure if (lib)xl ought to be special casing XS in this way, as >>> opposed >>> to adding a more generic concept such as e.g. permanent domains, which >>> would be true for the xs domain but also for other special domains in >>> the >>> future and could even be controlled by the user or toolstack (I'm >>> thinking >>> you might want to set the flag on a driver domain for example). >> >> The xs domain has to be handled separately, as it is needed to run in >> order to be able to stop other domains in a clean way. >> >> In case dom0 reboot will be supported we need two different reboot >> modes: one with a hypervisor reboot implying all domains will be >> stopped (including the xs domain), and one without hypervisor reboot >> implying that all domains not requiring dom0 to be up all time will >> still be running after dom0 is up again. >> >> For stopping all domains before doing a hypervisor reboot, driver >> domains should be stopped, too, but they should be stopped _after_ >> all other domains. And even then the xs domain should be still >> running when the driver domains are being stopped. > > So what we have is in effect some sort of reboot ordering or priority and a > threshold depending on what sort of reboot the host as a whole is > undergoing? I think so, yes. >> IMO the generic concept you are asking for should be added in a >> separate patch handling stopping (and possibly rebooting) driver >> domains in a clean way. > > Since libxl has a stable API once we add something we need to continue > supporting it, so we cannot (easily/cleanly) switch an xs specific scheme > into a generic one later. That argues then for supporting the XS case via > the generic mechanism now, even if we don't implement the other cases. I can't see a scenario where the xenstore domain would have to be stopped by dom0. Once you do it you'll never be able to connect to it again without changing the xenbus driver interface, too. It is the same reason why xenstored can't be restarted. Driver domains are different and I think the interface to query a domain whether it is a driver domain or whether it might survive a dom0 reboot should be based on xenstore. So a xenstore domain would always need special handling. Juergen
On Thu, 2016-01-07 at 11:44 +0100, Juergen Gross wrote: > > > IMO the generic concept you are asking for should be added in a > > > separate patch handling stopping (and possibly rebooting) driver > > > domains in a clean way. > > > > Since libxl has a stable API once we add something we need to continue > > supporting it, so we cannot (easily/cleanly) switch an xs specific > > scheme > > into a generic one later. That argues then for supporting the XS case > > via > > the generic mechanism now, even if we don't implement the other cases. > > I can't see a scenario where the xenstore domain would have to be > stopped by dom0. Once you do it you'll never be able to connect to > it again without changing the xenbus driver interface, too. It is > the same reason why xenstored can't be restarted. > > Driver domains are different and I think the interface to query a > domain whether it is a driver domain or whether it might survive a > dom0 reboot should be based on xenstore. > > So a xenstore domain would always need special handling. If there is really _never_ any reason to stop the xs domain then I think at the libxl API level a class of "never stop" domains would be better than special casing the xs, even if it turns out the only member of the set is xs at least we've given ourselves wriggle room if something else comes up in the future. Ian.
On 07/01/16 11:55, Ian Campbell wrote: > On Thu, 2016-01-07 at 11:44 +0100, Juergen Gross wrote: >>>> IMO the generic concept you are asking for should be added in a >>>> separate patch handling stopping (and possibly rebooting) driver >>>> domains in a clean way. >>> >>> Since libxl has a stable API once we add something we need to continue >>> supporting it, so we cannot (easily/cleanly) switch an xs specific >>> scheme >>> into a generic one later. That argues then for supporting the XS case >>> via >>> the generic mechanism now, even if we don't implement the other cases. >> >> I can't see a scenario where the xenstore domain would have to be >> stopped by dom0. Once you do it you'll never be able to connect to >> it again without changing the xenbus driver interface, too. It is >> the same reason why xenstored can't be restarted. >> >> Driver domains are different and I think the interface to query a >> domain whether it is a driver domain or whether it might survive a >> dom0 reboot should be based on xenstore. >> >> So a xenstore domain would always need special handling. > > If there is really _never_ any reason to stop the xs domain then I think at > the libxl API level a class of "never stop" domains would be better than > special casing the xs, even if it turns out the only member of the set is > xs at least we've given ourselves wriggle room if something else comes up > in the future. Okay, so this would translate to either: - add a "never stop" flag to libxl_dominfo (can I do this without breaking the API?) - add a new call interface to either check a single domain to be of the "never stop" class or to return a list of those domains. Preferences? Juergen
On Thu, 2016-01-07 at 12:21 +0100, Juergen Gross wrote: > On 07/01/16 11:55, Ian Campbell wrote: > > On Thu, 2016-01-07 at 11:44 +0100, Juergen Gross wrote: > > > > > IMO the generic concept you are asking for should be added in a > > > > > separate patch handling stopping (and possibly rebooting) driver > > > > > domains in a clean way. > > > > > > > > Since libxl has a stable API once we add something we need to > > > > continue > > > > supporting it, so we cannot (easily/cleanly) switch an xs specific > > > > scheme > > > > into a generic one later. That argues then for supporting the XS > > > > case > > > > via > > > > the generic mechanism now, even if we don't implement the other > > > > cases. > > > > > > I can't see a scenario where the xenstore domain would have to be > > > stopped by dom0. Once you do it you'll never be able to connect to > > > it again without changing the xenbus driver interface, too. It is > > > the same reason why xenstored can't be restarted. > > > > > > Driver domains are different and I think the interface to query a > > > domain whether it is a driver domain or whether it might survive a > > > dom0 reboot should be based on xenstore. > > > > > > So a xenstore domain would always need special handling. > > > > If there is really _never_ any reason to stop the xs domain then I > > think at > > the libxl API level a class of "never stop" domains would be better > > than > > special casing the xs, even if it turns out the only member of the set > > is > > xs at least we've given ourselves wriggle room if something else comes > > up > > in the future. > > Okay, so this would translate to either: > > - add a "never stop" flag to libxl_dominfo (can I do this without > breaking the API?) > - add a new call interface to either check a single domain to be of > the "never stop" class or to return a list of those domains. > > Preferences? Definitely the former, with a LIBXL_HAVE_ #define in libxl.h so consumers know they can use it. Wei, Ian, do you agree with this approach? Ian.
On Thu, Jan 07, 2016 at 06:37:34AM +0100, Juergen Gross wrote: > On 06/01/16 16:59, Ian Campbell wrote: > > On Fri, 2015-12-18 at 15:10 +0100, Juergen Gross wrote: > >> On 18/12/15 14:53, Andrew Cooper wrote: > >>> On 18/12/15 13:14, Juergen Gross wrote: > >>>> Add libxl_xenstore_domid() to obtain the domain id of the xenstore > >>>> domain. > >>>> > >>>> Signed-off-by: Juergen Gross <jgross@suse.com> > >>> > >>> What are the expected semantics here? Would you expect it to return > >>> domid 0 for a traditional setup, or are you wanting to use it as a > >>> "does > >>> a xenstored domain exist" test? > >> > >> The latter. It will be used in patch 13 to decide which domain to > >> stop via "xl shutdown --all". > > > > ITYM "not stop". > > Well, yes, if you select which domains to stop you select which domains > are not stopped, too. :-) > > I don't mind either wording. :-) > > > libxl already has interfaces for getting info about a > > domain, libxl_domain_info libxl_list_domain etc, it seems like this > > property should be added to that data rather than introducing a special > > purpose API to get it. Especially given that xl shutdown already calls > > libxl_list_domain. > > Okay, I can change it that way. > > > I'm unsure if (lib)xl ought to be special casing XS in this way, as opposed > > to adding a more generic concept such as e.g. permanent domains, which > > would be true for the xs domain but also for other special domains in the > > future and could even be controlled by the user or toolstack (I'm thinking > > you might want to set the flag on a driver domain for example). > > The xs domain has to be handled separately, as it is needed to run in > order to be able to stop other domains in a clean way. > > In case dom0 reboot will be supported we need two different reboot > modes: one with a hypervisor reboot implying all domains will be > stopped (including the xs domain), and one without hypervisor reboot > implying that all domains not requiring dom0 to be up all time will > still be running after dom0 is up again. > For so long we've lumped together so many things in Dom0, so it would be better there is clear definition what you would expect from rebooting Dom0. As far as I can tell, currently in a typical setup Dom0 serves at least several purposes: 1. Toosltack domain for managing VMs 2. Driver domain for physical devices 3. Running emulators 4. Provide some services to DomU (I know there are people who do that) Do we need provision for adding more flags or groups? One flag (as suggested in subthread) doesn't seem enough. Wei. > For stopping all domains before doing a hypervisor reboot, driver > domains should be stopped, too, but they should be stopped _after_ > all other domains. And even then the xs domain should be still > running when the driver domains are being stopped. > > IMO the generic concept you are asking for should be added in a > separate patch handling stopping (and possibly rebooting) driver > domains in a clean way. > > > Juergen
On 07/01/16 13:40, Wei Liu wrote: > On Thu, Jan 07, 2016 at 06:37:34AM +0100, Juergen Gross wrote: >> On 06/01/16 16:59, Ian Campbell wrote: >>> On Fri, 2015-12-18 at 15:10 +0100, Juergen Gross wrote: >>>> On 18/12/15 14:53, Andrew Cooper wrote: >>>>> On 18/12/15 13:14, Juergen Gross wrote: >>>>>> Add libxl_xenstore_domid() to obtain the domain id of the xenstore >>>>>> domain. >>>>>> >>>>>> Signed-off-by: Juergen Gross <jgross@suse.com> >>>>> >>>>> What are the expected semantics here? Would you expect it to return >>>>> domid 0 for a traditional setup, or are you wanting to use it as a >>>>> "does >>>>> a xenstored domain exist" test? >>>> >>>> The latter. It will be used in patch 13 to decide which domain to >>>> stop via "xl shutdown --all". >>> >>> ITYM "not stop". >> >> Well, yes, if you select which domains to stop you select which domains >> are not stopped, too. :-) >> >> I don't mind either wording. :-) >> >>> libxl already has interfaces for getting info about a >>> domain, libxl_domain_info libxl_list_domain etc, it seems like this >>> property should be added to that data rather than introducing a special >>> purpose API to get it. Especially given that xl shutdown already calls >>> libxl_list_domain. >> >> Okay, I can change it that way. >> >>> I'm unsure if (lib)xl ought to be special casing XS in this way, as opposed >>> to adding a more generic concept such as e.g. permanent domains, which >>> would be true for the xs domain but also for other special domains in the >>> future and could even be controlled by the user or toolstack (I'm thinking >>> you might want to set the flag on a driver domain for example). >> >> The xs domain has to be handled separately, as it is needed to run in >> order to be able to stop other domains in a clean way. >> >> In case dom0 reboot will be supported we need two different reboot >> modes: one with a hypervisor reboot implying all domains will be >> stopped (including the xs domain), and one without hypervisor reboot >> implying that all domains not requiring dom0 to be up all time will >> still be running after dom0 is up again. >> > > For so long we've lumped together so many things in Dom0, so it would be > better there is clear definition what you would expect from rebooting > Dom0. > > As far as I can tell, currently in a typical setup Dom0 serves at least > several purposes: > > 1. Toosltack domain for managing VMs > 2. Driver domain for physical devices > 3. Running emulators > 4. Provide some services to DomU (I know there are people who do that) > > Do we need provision for adding more flags or groups? One flag (as > suggested in subthread) doesn't seem enough. Which information do we really need in dominfo? I suspect all but the xenstore flag would be better retrieved from xenstore via a different interface. I don't think we want that information in the hypervisor as well, so xenstore is the only alternative surviving a potential dom0 reboot. And libxl_list_domain() isn't reading xenstore today and it shouldn't do so in future. Juergen
On Thu, Jan 07, 2016 at 01:57:44PM +0100, Juergen Gross wrote: > On 07/01/16 13:40, Wei Liu wrote: > > On Thu, Jan 07, 2016 at 06:37:34AM +0100, Juergen Gross wrote: > >> On 06/01/16 16:59, Ian Campbell wrote: > >>> On Fri, 2015-12-18 at 15:10 +0100, Juergen Gross wrote: > >>>> On 18/12/15 14:53, Andrew Cooper wrote: > >>>>> On 18/12/15 13:14, Juergen Gross wrote: > >>>>>> Add libxl_xenstore_domid() to obtain the domain id of the xenstore > >>>>>> domain. > >>>>>> > >>>>>> Signed-off-by: Juergen Gross <jgross@suse.com> > >>>>> > >>>>> What are the expected semantics here? Would you expect it to return > >>>>> domid 0 for a traditional setup, or are you wanting to use it as a > >>>>> "does > >>>>> a xenstored domain exist" test? > >>>> > >>>> The latter. It will be used in patch 13 to decide which domain to > >>>> stop via "xl shutdown --all". > >>> > >>> ITYM "not stop". > >> > >> Well, yes, if you select which domains to stop you select which domains > >> are not stopped, too. :-) > >> > >> I don't mind either wording. :-) > >> > >>> libxl already has interfaces for getting info about a > >>> domain, libxl_domain_info libxl_list_domain etc, it seems like this > >>> property should be added to that data rather than introducing a special > >>> purpose API to get it. Especially given that xl shutdown already calls > >>> libxl_list_domain. > >> > >> Okay, I can change it that way. > >> > >>> I'm unsure if (lib)xl ought to be special casing XS in this way, as opposed > >>> to adding a more generic concept such as e.g. permanent domains, which > >>> would be true for the xs domain but also for other special domains in the > >>> future and could even be controlled by the user or toolstack (I'm thinking > >>> you might want to set the flag on a driver domain for example). > >> > >> The xs domain has to be handled separately, as it is needed to run in > >> order to be able to stop other domains in a clean way. > >> > >> In case dom0 reboot will be supported we need two different reboot > >> modes: one with a hypervisor reboot implying all domains will be > >> stopped (including the xs domain), and one without hypervisor reboot > >> implying that all domains not requiring dom0 to be up all time will > >> still be running after dom0 is up again. > >> > > > > For so long we've lumped together so many things in Dom0, so it would be > > better there is clear definition what you would expect from rebooting > > Dom0. > > > > As far as I can tell, currently in a typical setup Dom0 serves at least > > several purposes: > > > > 1. Toosltack domain for managing VMs > > 2. Driver domain for physical devices > > 3. Running emulators > > 4. Provide some services to DomU (I know there are people who do that) > > > > Do we need provision for adding more flags or groups? One flag (as > > suggested in subthread) doesn't seem enough. > > Which information do we really need in dominfo? I suspect all but the > xenstore flag would be better retrieved from xenstore via a different > interface. I don't think we want that information in the hypervisor > as well, so xenstore is the only alternative surviving a potential Using Xenstore to store domain type would work, too. That would be one way of "provision" to me. I was thinking about having more flags in HV but in the end I deemed it a bad idea myself so I just asked you about your thought. So now the absolute bare minimum setup for Xen system is the hypervisor plus xenstore domain. I think that's fine as long as it is clearly communicated and agreed upon. :-) Wei. > dom0 reboot. And libxl_list_domain() isn't reading xenstore today > and it shouldn't do so in future. > > > Juergen
On Thu, Jan 07, 2016 at 11:36:08AM +0000, Ian Campbell wrote: > On Thu, 2016-01-07 at 12:21 +0100, Juergen Gross wrote: > > On 07/01/16 11:55, Ian Campbell wrote: > > > On Thu, 2016-01-07 at 11:44 +0100, Juergen Gross wrote: > > > > > > IMO the generic concept you are asking for should be added in a > > > > > > separate patch handling stopping (and possibly rebooting) driver > > > > > > domains in a clean way. > > > > > > > > > > Since libxl has a stable API once we add something we need to > > > > > continue > > > > > supporting it, so we cannot (easily/cleanly) switch an xs specific > > > > > scheme > > > > > into a generic one later. That argues then for supporting the XS > > > > > case > > > > > via > > > > > the generic mechanism now, even if we don't implement the other > > > > > cases. > > > > > > > > I can't see a scenario where the xenstore domain would have to be > > > > stopped by dom0. Once you do it you'll never be able to connect to > > > > it again without changing the xenbus driver interface, too. It is > > > > the same reason why xenstored can't be restarted. > > > > > > > > Driver domains are different and I think the interface to query a > > > > domain whether it is a driver domain or whether it might survive a > > > > dom0 reboot should be based on xenstore. > > > > > > > > So a xenstore domain would always need special handling. > > > > > > If there is really _never_ any reason to stop the xs domain then I > > > think at > > > the libxl API level a class of "never stop" domains would be better > > > than > > > special casing the xs, even if it turns out the only member of the set > > > is > > > xs at least we've given ourselves wriggle room if something else comes > > > up > > > in the future. > > > > Okay, so this would translate to either: > > > > - add a "never stop" flag to libxl_dominfo (can I do this without > > breaking the API?) > > - add a new call interface to either check a single domain to be of > > the "never stop" class or to return a list of those domains. > > > > Preferences? > > Definitely the former, with a LIBXL_HAVE_ #define in libxl.h so consumers > know they can use it. > > Wei, Ian, do you agree with this approach? > My concern in other sub-thread is addressed so this approach is fine by me. Wei. > Ian.
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 9207621..3bcff59 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -701,6 +701,30 @@ int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo *info_r, return 0; } +int libxl_xenstore_domid(libxl_ctx *ctx, uint32_t *domid) +{ + xc_dominfo_t info; + uint32_t last_domid; + int ret; + GC_INIT(ctx); + + for (last_domid = 0; + (ret = xc_domain_getinfo(ctx->xch, last_domid, 1, &info)) == 1; + last_domid = info.domid + 1) + { + if (info.xs_domain) + { + *domid = info.domid; + ret = 0; + goto out; + } + } + ret = (ret == 0) ? ERROR_DOMAIN_NOTFOUND : ERROR_FAIL; +out: + GC_FREE; + return ret; +} + /* Returns: * 0 - success * ERROR_FAIL + errno == ENOENT - no entry found diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 05606a7..41e9d88 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -867,6 +867,13 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, libxl_mac *src); */ #define LIBXL_HAVE_DEVICE_MODEL_VERSION_NONE 1 +/* + * LIBXL_HAVE_XENSTORE_DOMID + * + * If this is defined, then libxl_xenstore_domid is available. + */ +#define LIBXL_HAVE_XENSTORE_DOMID + typedef char **libxl_string_list; void libxl_string_list_dispose(libxl_string_list *sl); int libxl_string_list_length(const libxl_string_list *sl); @@ -1306,6 +1313,10 @@ int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num, */ int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm, char **path); +/* Save domid of a possible Xenstore domain. If no Xenstore domain exists, + * ERROR_DOMAIN_NOTFOUND is returned. */ +int libxl_xenstore_domid(libxl_ctx *ctx, uint32_t *domid); + /* May be called with info_r == NULL to check for domain's existence. * Returns ERROR_DOMAIN_NOTFOUND if domain does not exist (used to return * ERROR_INVAL for this scenario). */
Add libxl_xenstore_domid() to obtain the domain id of the xenstore domain. Signed-off-by: Juergen Gross <jgross@suse.com> --- tools/libxl/libxl.c | 24 ++++++++++++++++++++++++ tools/libxl/libxl.h | 11 +++++++++++ 2 files changed, 35 insertions(+)