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

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