Re: [Xen-devel] [PATCH v2 03/13] libxl: provide a function to retrieve the xenstore domain id

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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@xxxxxxxx>
> > > > 
> > > > 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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel