On 22.04.24 09:12, 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?
I have no plans to remove it.
Juergen
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
