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, 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 number >> >> of control domains (perhaps with some coordination between >> >> them). >> > >> > Right. So XENFEAT_dom0 is not really what Olaf needs. >> >> Sigh. What does "has access to all the hardware" translate to >> for you? > >That would mean hardware domain. > >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. > >Can you point me to the start of your discussion with Olaf so that I can >check what the disagreement between you and Olaf is about? The start of the discussion is the root of this thread. Olaf somewhere in the middle pointed to another discussion which you appear to have been involved in. I'm also not sure there's actual disagreement here - I was merely pointing out that strictly following what was written in the description of the patch there may not be a need to consult /proc/xen, and hence no need to mount it early. Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 get the flag? >> >> There can only be one hardware domain, which will continue to >> be the one getting XENFEAT_dom0. There could be any number >> of control domains (perhaps with some coordination between >> them). > > Right. So XENFEAT_dom0 is not really what Olaf needs. Sigh. What does "has access to all the hardware" translate to for you? Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 number of control domains (perhaps with some coordination between them). Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 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. I understood it exactly the other way around: The question is whether to treat things the same as without Xen: "dom0 has to be handled as "no virtualization" because it has access to all hardware, all services depending on "native" have to run in dom0." Sound like hardware domain to me, not control domain. Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 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? Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 virtualization" because it has access to > all hardware, all services depending on "native" have to run in dom0. 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). Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[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 exists, or some sysfs files indicate "xen", > VIRTUALIZATION_XEN should be set to indicate the system is a domU. > > With an (old) xenlinux based kernel, /proc/xen/capabilities is always > available and the detection described above works always. But with a > pvops based kernel, xenfs must be mounted on /proc/xen to get > "capabilities". Up to now this was done by a proc-xen.mount unit, which > is part of xen.git. Since the mounting happens "late", other units may > be scheduled before "proc-xen.mount". If these other units make use of > "ConditionVirtualisation=", the virtualization detection returns > incorect results. detect_vm() will set VIRTUALIZATION_XEN because "xen" > is found in sysfs. This value will be cached. Once xenfs is mounted, > the next process that runs detect_vm() will get VIRTUALIZATION_NONE. With all of the above, was it considered to check /sys/hypervisor alongside with or perhaps even in preference to /proc/xen? Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 dom0. 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. Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
