From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH v2 03/13] libxl: provide a function to retrieve the xenstore domain id Date: Thu, 7 Jan 2016 13:57:44 +0100 Message-ID: <568E60C8.6020408@suse.com> References: <1450444471-6454-1-git-send-email-jgross@suse.com> <1450444471-6454-4-git-send-email-jgross@suse.com> <56740FC2.4030504@citrix.com> <567413E8.3010301@suse.com> <1452095954.21055.98.camel@citrix.com> <568DF99E.9010503@suse.com> <20160107124042.GW27789@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160107124042.GW27789@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Ian Campbell , stefano.stabellini@eu.citrix.com, Andrew Cooper , ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org 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 >>>>> >>>>> 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