From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olaf Hering <olaf@aepfle.de>
Subject: Re: [PATCH v1] core: mount xenfs,
 ignore proc-xen.mount (#6442, #6662)
Date: Fri, 1 Dec 2017 12:04:55 +0100
Message-ID: <20171201120455.6e8877fb.olaf@aepfle.de>
References: <20171129153842.14353-1-olaf@aepfle.de>
 <5A1EE45A0200007800193358@prv-mh.provo.novell.com>
 <20171129155457.GB5299@aepfle.de>
 <5A1EE7F40200007800193394@prv-mh.provo.novell.com>
 <20171129160742.GC5299@aepfle.de>
 <5A1EED6702000078001933EF@prv-mh.provo.novell.com>
 <20171130082355.GC3073@aepfle.de>
 <5A1FD0F10200007800193657@prv-mh.provo.novell.com>
 <20171201102146.m27cpsgm2jjcomgl@citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8215545506279613442=="
Return-path: <xen-devel-bounces@lists.xenproject.org>
In-Reply-To: <20171201102146.m27cpsgm2jjcomgl@citrix.com>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
To: Wei Liu <wei.liu2@citrix.com>
Cc: systemd-devel@lists.freedesktop.org, Vasilis Liaskovitis <vliaskovitis@suse.com>, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

--===============8215545506279613442==
Content-Type: multipart/signed; micalg=pgp-sha1;
 boundary="Sig_/IHg+wA/UuiiJ0thnSrT9/ty"; protocol="application/pgp-signature"

--Sig_/IHg+wA/UuiiJ0thnSrT9/ty
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Am Fri, 1 Dec 2017 10:21:46 +0000
schrieb Wei Liu <wei.liu2@citrix.com>:

> 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 think this is not entirely accurate. Right now the term "dom0" is=20
a mix of "has access to host (IO) hardware" and "runs the toolstack".

ConditionVirtualization=3D today lacks such details as well.
"xen" means domU, and "none" is dom0, simply to handle "dom0" like "native"
so that all services that want access to "host hardware" can start.

One could argue that passing a PCI device to a domU may also require
.service files to manage that PCI device in some way. The specifc case
which triggered all the suggested changes was smartd, which is not
supposed to run in "VMs". If a SATA card is provided to a domU it may
be a good idea to monitor the attached disks as well.

So in some way Jan is correct with his suggestion to use XENFEAT_dom0
instead of "control_d". I will do some research about when it became availa=
ble
and update the patch description.

Olaf

--Sig_/IHg+wA/UuiiJ0thnSrT9/ty
Content-Type: application/pgp-signature
Content-Description: Digitale Signatur von OpenPGP

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQSkRyP6Rn//f03pRUBdQqD6ppg2fgUCWiE3VwAKCRBdQqD6ppg2
fhyBAJsHWyaFLM2RzornjTPzY7ulK52hKgCgybo5eT/ndH1uU+ZQZFaW3pN8d7s=
=ZEEa
-----END PGP SIGNATURE-----

--Sig_/IHg+wA/UuiiJ0thnSrT9/ty--


--===============8215545506279613442==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0
cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA==

--===============8215545506279613442==--