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 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 <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. :-)
>>
>>> 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
dom0 reboot. And libxl_list_domain() isn't reading xenstore today
and it shouldn't do so in future.


Juergen

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