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. Other than adding a new interface to Xen, is there any way to tell if Xen is running in a VM? If we do need to expose an interface, what would be the best way to do that? -George
