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 06:37:34 +0100 Message-ID: <568DF99E.9010503@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1452095954.21055.98.camel@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: Ian Campbell , Andrew Cooper , xen-devel@lists.xen.org, ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com, dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org 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 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