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

From: Wei Liu <wei.liu2@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: systemd-devel@lists.freedesktop.org,
	Wei Liu <wei.liu2@citrix.com>,
	Vasilis Liaskovitis <vliaskovitis@suse.com>,
	Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)
Date: Fri, 1 Dec 2017 13:00:45 +0000	[thread overview]
Message-ID: <20171201130045.ekrvod6sflu3ngkm@citrix.com> (raw)
In-Reply-To: <20171201133848.140d2063.olaf@aepfle.de>

On Fri, Dec 01, 2017 at 01:38:48PM +0100, Olaf Hering wrote:
> Am Fri, 1 Dec 2017 12:29:24 +0000
> schrieb Wei Liu <wei.liu2@citrix.com>:
> 
> > But Olaf needs to know if some of the services like xenconsoled or
> > xenstored should be started, and if some of the special file systems
> > should be mounted, right? Those aren't tied to hardware in anyway. In my
> > view that's the responsibility of the toolstack control domain.
> 
> No, I did not intent to make use of ConditionVirtualization= in the
> xen*.service files in tools/hotplug/Linux/. That variable can not be used
> for this purpose, and the patch would not change that.
> 
> In case you refer to the "proc-xen.mount" change from a few days/weeks ago,
> this was all about avoiding the error when xenfs becomes an "API filesystem".
> With this suggested change the existing "proc-xen.mount units would not fail
> anymore because /proc/xen is added to the ignore list.
> 

Yes, but then there are further services that depend on proc-xen.mount.
Say, xenstored and xenconsoled. That's why I came to the conclusion that
XENFEAT_dom0 (denoting hardware domain, as Jan said, could be a
different domain from control domain down the road) wasn't what you
want.

Quote from the first email in this thread that I'm CC'ed:

>> 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.

Obv. Jan thinks sysfs contains what you want, but afaict I had a
different conclusion.

I don't think there is misunderstanding as to what that flag means.  I
sense that there is misunderstanding as what you want to achieve.
Or maybe Jan means the flag (or the absence of it) can already give you
the information you need?

What information do you need? For a moment let's skip using the fuzzy
"Dom0" term and try to be precise. Like "I would like to know if that
domain has access to all hardware" or something else.

Wei.

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