[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 03/13] libxl: provide a function to retrieve the xenstore domain id
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 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |