[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 Fri, Dec 01, 2017 at 04:39:30AM -0700, Jan Beulich wrote: > >>> On 01.12.17 at 11:21, <wei.liu2@xxxxxxxxxx> wrote: > > 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. > > 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. > Software services needed to run a Xen system are handled by sysmted/sysv init. They depend on the detection of control domain, not hardware domain. I think that's what Olaf is after mostly. Suppose at one point we split hardware domain and control domain, which one will you call Dom0? Which one will get the flag? Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |