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

On Fr, 01.12.17 12:04, Olaf Hering (o...@aepfle.de) wrote: > Am Fri, 1 Dec 2017 10:21:46 + > schrieb Wei Liu : > > > 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

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

>>> Wei Liu 12/01/17 1:30 PM >>> >On Fri, Dec 01, 2017 at 05:23:16AM -0700, Jan Beulich wrote: >> >>> On 01.12.17 at 13:15, wrote: >> > On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote: >> >> >>> On 01.12.17 at 12:48,

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

On Fri, Dec 01, Wei Liu wrote: > 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. That depends on the .service files. This is the list of openSUSE

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

Am Fri, 1 Dec 2017 12:29:24 + schrieb Wei Liu : > 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

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

>>> On 01.12.17 at 13:15, wrote: > On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote: >> >>> On 01.12.17 at 12:48, wrote: >> > Suppose at one point we split hardware domain and control domain, which >> > one will you call Dom0? Which one will

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

>>> On 01.12.17 at 12:48, wrote: > Suppose at one point we split hardware domain and control domain, which > one will you call Dom0? Which one will get the flag? There can only be one hardware domain, which will continue to be the one getting XENFEAT_dom0. There could be any

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

>>> On 01.12.17 at 11:21, wrote: > On Thu, Nov 30, 2017 at 01:35:45AM -0700, Jan Beulich wrote: >> >>> On 30.11.17 at 09:23, 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

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

Am Fri, 1 Dec 2017 10:21:46 + schrieb Wei Liu : > 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

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

>>> On 30.11.17 at 09:23, 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

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

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

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

On Wed, Nov 29, Jan Beulich wrote: > But in the description you talk about detect_vm() - by its name that > doesn't look to care about Dom0, but whether running on top of > _some_ hypervisor. dom0 has to be handled as "no virtualization" because it has access to all hardware, all services

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

>>> On 29.11.17 at 17:07, wrote: > On Wed, Nov 29, Jan Beulich wrote: > >> But in the description you talk about detect_vm() - by its name that >> doesn't look to care about Dom0, but whether running on top of >> _some_ hypervisor. > > dom0 has to be handled as "no

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

>>> On 29.11.17 at 16:38, wrote: > The detection of ConditionVirtualisation= relies on the presence of > /proc/xen/capabilities. If the file exists and contains the string > "control_d", the running system is a dom0 and VIRTUALIZATION_NONE should > be set. In case /proc/xen

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

On Wed, Nov 29, Jan Beulich wrote: > With all of the above, was it considered to check /sys/hypervisor > alongside with or perhaps even in preference to /proc/xen? Yes. /proc/xen/capabilities is the one and only place that indicates a dom0. Olaf signature.asc Description: PGP signature

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

>>> On 29.11.17 at 16:54, wrote: > On Wed, Nov 29, Jan Beulich wrote: > >> With all of the above, was it considered to check /sys/hypervisor >> alongside with or perhaps even in preference to /proc/xen? > > Yes. > /proc/xen/capabilities is the one and only place that indicates a