Re: [Xen-devel] [PATCH v2 13/13] tools: don't stop xenstore domain when stopping dom0

[Juergen Gross <jgross@xxxxxxxx>]

On 07/01/16 11:34, Ian Campbell wrote:
> On Thu, 2016-01-07 at 07:52 +0100, Juergen Gross wrote:
>> On 06/01/16 17:33, Ian Campbell wrote:
>>> On Fri, 2015-12-18 at 15:53 +0100, Juergen Gross wrote:
>>>> On 18/12/15 15:42, Andrew Cooper wrote:
>>>>> On 18/12/15 13:14, Juergen Gross wrote:
>>>>>> When restarting or shutting down dom0 the xendomains script tries
>>>>>> to
>>>>>> stop all other domains. Don't do this for the xenstore domain, as
>>>>>> it
>>>>>> might survive a dom0 reboot in the future.
>>>>>>
>>>>>> The same applies to xl shutdown --all.
>>>>>>
>>>>>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
>>>>>> ---
>>>>>>  tools/hotplug/Linux/xendomains.in | 17 +++++++++++++++++
>>>>>>  tools/libxl/xl_cmdimpl.c          | 19 +++++++++++++++----
>>>>>>  2 files changed, 32 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/tools/hotplug/Linux/xendomains.in
>>>>>> b/tools/hotplug/Linux/xendomains.in
>>>>>> index dfe0b33..70b7f16 100644
>>>>>> --- a/tools/hotplug/Linux/xendomains.in
>>>>>> +++ b/tools/hotplug/Linux/xendomains.in
>>>>>> @@ -196,6 +196,17 @@ rdnames()
>>>>>>      done
>>>>>>  }
>>>>>>  
>>>>>> +# set xenstore domain id (or 0 if no xenstore domain)
>>>>>> +get_xsdomid()
>>>>>
>>>>> A get/set mismatch.
>>>>
>>>> Hmm, depends.
>>>>
>>>> It is getting the domid of the xenstore domain and is setting
>>>> XS_DOMID accordingly. The main semantics are to get the correct
>>>> domid.
>>>>
>>>>>
>>>>>> +{
>>>>>> +    ${bindir}/xenstore-exists /tool/xenstored/domid
>>>>>> +    if test $? -ne 0; then
>>>>>> +        XS_DOMID=0
>>>>>> +    else
>>>>>> +        XS_DOMID=`${bindir}/xenstore-read /tool/xenstored/domid`
>>>
>>> Please update docs/misc/xenstore-paths.markdown with this.
>>
>> Okay.
>>
>>>
>>> Did you mean /tools?
>>
>> No. The xenstore path is /tool/...
> 
> You mean that are preexisting uses of this path?
> 
> /me looks.
> 
> Oh, so there is. Undocumented too :-(
> 
>>>
>>> Earlier in the series there was a patch which looped over xc_dom_info
>>> looking for the xs domain -- if this is in xenstore can't it use that?
>>
>> Hen and egg problem. You need to know how to connect to xenstore
>> (domain or daemon) before being able to read xenstore.
> 
> Oh, of course.
> 
> Can you not infer from the presence of absence of the sockets in the local
> f/s or do they always exist (i.e. stale from a previous configuration)?

No. Sockets will be created later even in the xenstored case. And still
you need to know the domain id of the xenstore domain in order to be
able to connect to it. This is available in the hypervisor and the
xenstore domain only at this time.

> We did once try switching to always using the domain ring, even if the
> client and server were co-located in the same domain, but that can result
> in uninterruptible sleeps in the kernel IIRC (a bug which might have since
> been fixed, not sure). Anyway, that probably rules out the "solution" of
> always using the domain.
> 
> The daemon would drop a pid file, but I suppose that might also be stale.
> 
> I'm mostly just brainstorming here, I don't really have a problem with the
> scan in the earlier patch.
> 
> (FWIW in English idiom we usually say chicken and egg BTW)

Aah, thanks.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel