[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.