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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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@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. :-)
> 
> > 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

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