Re: Detecting whether dom0 is in a VM

[zithro <slack@xxxxxxxxx>]

On 05 Jul 2023 17:51, George Dunlap wrote:
> Hey all,
>
> The following systemd issue was brought to my attention:
>
> https://github.com/systemd/systemd/issues/28113
>
> I think basically, they want `systemd-detect-virt` return the following
> values:
>
> Xen on hardware, from a dom0:  `none`
> Xen on hardware, from a domU: `xen`
> Xen in a VM, from a dom0: (ideally the virtualization type, or `vm-other`
> if not)
> Xen in a VM, from a domU: `xen`
>
> Is there a reliable set of tests which would work across all dom0 guest
> types / architectures?  If not, can we expose the information somehow?
>
>   -George
Small follow-up, I did some more tests (AMD platforms).
systemd-detect-virt (sdv) is using "/sys/class/dmi/id/sys_vendor".

On both "baremetal" dom0s, sdv is reporting the platform manufacturer 
("MSI" or "Micro-Star International Co., Ltd." on my systems).
On a nested dom0, sdv is reporting "xen" :
  root@xen-nested:~# SYSTEMD_LOG_LEVEL=debug systemd-detect-virt
  Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
  Found container virtualization none.
  Virtualization Xen found in DMI (/sys/class/dmi/id/sys_vendor)
  Found VM virtualization xen
  xen

PS: my host "xen-nested" is not masking CPUID leaves in cfg file.

So I'm wondering, isn't that path enough for correct detection ?
I mean, if "/sys/class/dmi/id/sys_vendor" reports Xen (or KVM, or any 
other known hypervisor), it's nested, otherwise it's on hardware ?
Is that really mandatory to use CPUID leaves ?