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? Jan > 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
