From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: xenstore domain Date: Wed, 9 Dec 2015 08:34:21 +0100 Message-ID: <5667D97D.5050604@suse.com> References: <5666ECBE.6090102@suse.com> <5666F16D.7040804@citrix.com> <5666FF19.5020200@suse.com> <56670685.4060407@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56670685.4060407@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: Andrew Cooper , "xen-devel@lists.xen.org" , David Scott List-Id: xen-devel@lists.xenproject.org On 08/12/15 17:34, Andrew Cooper wrote: > On 08/12/15 16:02, Juergen Gross wrote: >> On 08/12/15 16:04, Andrew Cooper wrote: >>> On 08/12/15 14:44, Juergen Gross wrote: >>>> I'm just playing a little bit with xenstore in an own domain. >>>> >>>> I've come across some questions I'd like to have some answers to before >>>> presenting official patches to make this an easy configurable option: >>>> >>>> a) As this would need a boot time configuration item I'd like to add >>>> e.g. /etc/xen/server.conf where such global configuration options >>>> could be set via directives. Is this generally okay? If yes, which >>>> format? Easiest way would be entries like >>>> VAR=value >>>> which can be either sourced in from shell scripts or can easily be >>>> parsed in all programming languages. What are the preferences here? >>> Any configuration like this going to be toolstack-specific. I would >>> recommend against using a name as generic as that. >>> >>> /etc/xl.conf already exists, which IMO would be the natural place for >>> this to live, but it isn't parseable by shell, because of vif notation. >> OTOH that file wouldn't be just for xl. It would be consumed by e.g. >> xencommons. Other configuration options I'd plan to add would be >> driver domains dedicated to specific interface cards. > > It is still logically part of the "xl toolstack infrastructure", but I > accept your point. The current xl.conf is all about how to create > domains in general, rather than specifically "how I would like my system > configured when starting up". > >> >>> One option might be to alter xl.conf to be compatible with shell >>> parsing. It wouldn't be complicated (even in upgrade situations), and >>> would offer rather more flexibility. >> Shell parsing could be even handled via a rather simple filter, I guess. >> >>>> b) Today init-xenstore-domain will require flask to be enabled. An >>>> alternative would be to add a new domain creation flag to allow the >>>> domains with that flag set calling xc_domain_getinfo(). Thoughts? >>> Which flag? >> A new domcr_flag. > > Indicating what, precisely? What I need is the capability to do the XEN_DOMCTL_getdomaininfo hypercall from the xenstore domain. Question is whether it's better to tie this special capability to the flag or to name it "is_xenstore". Thinking more about it, especially regarding a possible enhancement allowing Dom0 to reboot, I think the is_xenstore variant would be better. This would allow to look whether a xenstore domain is already running and connect to that rather than try to start a new one. Juergen