On Mon, 22 Apr 2024, Jan Beulich wrote: > On 19.04.2024 17:29, George Dunlap wrote: > > On Fri, Jul 7, 2023 at 3:56 PM George Dunlap <george.dun...@cloud.com> > > wrote: > >>>>>> Xen's public interface offers access to the featuresets known / found / > >>>>>> used by the hypervisor. See XEN_SYSCTL_get_cpu_featureset, accessible > >>>>>> via xc_get_cpu_featureset(). > >>>>>> > >>>>> > >>>>> Are any of these exposed in dom0 via sysctl, or hypfs? > >>>> > >>>> sysctl - yes (as the quoted name also says). hypfs no, afaict. > >>>> > >>>>> SYSCTLs are > >>>>> unfortunately not stable interfaces, correct? So it wouldn't be > >>>>> practical > >>>>> for systemd to use them. > >>>> > >>>> Indeed, neither sysctl-s nor the libxc interfaces are stable. > >>> > >>> Thinking of it, xen-cpuid is a wrapper tool around those. They may want > >>> to look at its output (and, if they want to use it, advise distros to > >>> also package it), which I think we try to keep reasonably stable, > >>> albeit without providing any guarantees. > >> > >> > >> We haven't had any clear guidance yet on what the systemd team want in the > >> <xen in a VM, systemd in a dom0> question; I just sort of assumed they > >> wanted the L-1 virtualization *if possible*. It sounds like `vm-other` > >> would be acceptable, particularly as a fall-back output if there's no way > >> to get Xen's picture of the cpuid. > >> > >> It looks like xen-cpuid is available on Fedora, Debian, Ubuntu, and the > >> old Virt SIG CentOS packages; so I'd expect most packages to follow suit. > >> That's a place to start. > >> > >> Just to take the discussion all the way to its conclusion: > >> > >> - Supposing xen-cpuid isn't available, is there any other way to tell if > >> Xen is running in a VM from dom0? > >> > >> - Would it make sense to expose that information somewhere, either in > >> sysfs or in hypfs (or both?), so that eventually even systems which may > >> not get the memo about packaging xen-cpuid will get support (or if the > >> systemd guys would rather avoid executing another process if possible)? > > > > Resurrecting this thread. > > > > To recap: > > > > Currently, `systemd-detect-virt` has the following input / output table: > > > > 1. Xen on real hardware, domU: xen > > 2. Xen on real hardware, dom0: vm-other > > 3. Xen in a VM, domU: xen > > 4. Xen in aVM, dom0: vm-other > > > > It's the dom0 lines (2 and 4) which are problematic; we'd ideally like > > those to be `none` and `vm-other` (or the actual value, like `xen` or > > `kvm`). > > > > It looks like ATM, /proc/xen/capabilities will contain `control_d` if > > it's a dom0. Simply unilaterally returning `none` if > > /proc/xen/capabilities contains `control_d` would correct the vast > > majority of instances (since the number of instances of Xen on real > > hardware is presumably higher than the number running virtualized). > > > > Is /proc/xen/capabilities expected to stay around? I don't see > > anything equivalent in /dev/xen. > > I believe it's intended to stay around, but a definitive answer can only > come from Linux folks. Jürgen, Stefano?
No plans to get rid of /proc/xen/capabilities that I am aware
