Re: Detecting whether dom0 is in a VM

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.dunlap@xxxxxxxxx> 
> > 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