From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [PATCH v2 03/13] libxl: provide a function to retrieve the xenstore domain id Date: Thu, 7 Jan 2016 13:13:08 +0000 Message-ID: <20160107131308.GX27789@citrix.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> <568E60C8.6020408@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <568E60C8.6020408@suse.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: Juergen Gross Cc: Wei Liu , 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 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 > >>>>> > >>>>> 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