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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Nov 30, 2017 at 01:35:45AM -0700, Jan Beulich wrote:
> >>> On 30.11.17 at 09:23, <olaf@xxxxxxxxx> 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.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel