Re: [Xen-devel] [PATCH v2 03/13] libxl: provide a function to retrieve the xenstore domain id

[Juergen Gross <jgross@xxxxxxxx>]

On 07/01/16 11:11, Ian Campbell wrote:
> On Thu, 2016-01-07 at 06:37 +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 <jgross@xxxxxxxx>
>>>>>
>>>>> 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. :-)
> 
> In the sense you meant I think you want "domains".

Indeed.

>>> 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.
> 
> So what we have is in effect some sort of reboot ordering or priority and a
> threshold depending on what sort of reboot the host as a whole is
> undergoing?

I think so, yes.

>> 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.
> 
> Since libxl has a stable API once we add something we need to continue
> supporting it, so we cannot (easily/cleanly) switch an xs specific scheme
> into a generic one later. That argues then for supporting the XS case via
> the generic mechanism now, even if we don't implement the other cases.

I can't see a scenario where the xenstore domain would have to be
stopped by dom0. Once you do it you'll never be able to connect to
it again without changing the xenbus driver interface, too. It is
the same reason why xenstored can't be restarted.

Driver domains are different and I think the interface to query a
domain whether it is a driver domain or whether it might survive a
dom0 reboot should be based on xenstore.

So a xenstore domain would always need special handling.


Juergen


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