[systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Jan Beulich]

>>> On 01.12.17 at 11:21, <wei.liu2 at citrix.com> wrote:
> On Thu, Nov 30, 2017 at 01:35:45AM -0700, Jan Beulich wrote:
>> >>> On 30.11.17 at 09:23, <olaf at aepfle.de> wrote:
>> > On Wed, Nov 29, Jan Beulich wrote:
>> > 
>> >> Ah, I see. But then still I don't see why at least on half way
>> >> recent Xen /sys/hypervisor/properties/features wouldn't have
>> >> the information you're after (and even more precise, because
>> >> down the road control domain and hardware domain may be
>> >> separate entities).
>> > 
>> > Per discussion in https://github.com/systemd/systemd/pull/6662, the
>> > feature bits should not be used for dom0 detection.
>> 
>> I can't seem to interpret that discussion the way you do. In fact
>> (as I've said before) using the feature flag is more reliable, as it
>> being set implies this is the hardware domain (rather than the
>> more fuzzy "control domain" implied by "control_d").
>> 
>> Wei, your comments there from Oct 27 and 30 are what I think
>> Olaf refers to. Could you clarify this?
>> 
> 
> Judging from the snippet here I don't quite understand what your
> disagreement is. You already said control domain and hardware domain
> could be separate entities in the future.
> 
> The XENFEAT_dom0 flag currently denotes hardware domain. It boils down
> to whether we want Dom0 to mean hardware domain, control domain or just
> "A domain that has domid 0".
> 
> In Olaf's case, he cares about knowing whether the domain runs the
> controlling toolstack, he doesn't care about if it is the hardware
> domain or not, so my conclusion was using that flag was wrong.

I understood it exactly the other way around: The question is
whether to treat things the same as without Xen:
"dom0 has to be handled as "no virtualization" because it has access to
 all hardware, all services depending on "native" have to run in dom0."
Sound like hardware domain to me, not control domain.

Jan