Re: Detecting whether dom0 is in a VM

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.07.2023 18:20, zithro wrote:
> 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 ?

Let me ask the other way around: In user mode code under a non-nested
vs nested Xen, what would you be able to derive from CPUID? The
"hypervisor" bit is going to be set in both cases. (All assuming you
run on new enough hardware+Xen such that CPUID would be intercepted
even for PV.)

Yet relying on DMI is fragile, too: Along the lines of
https://lists.xen.org/archives/html/xen-devel/2022-01/msg00604.html
basically any value in there could be "inherited" from the host (i.e.
from the layer below, to be precise). The only way to be reasonably
certain is to ask Xen about its view. The raw or host featuresets
should give you this information, in the "mirror" of said respective
CPUID leave's "hypervisor" bit. But of course that still won't tell
you which _kind_ of hypervisor is the immediate next one underneath
Xen.

This then further raises the question of what use it is to know the
kind of the next level hypervisor, when multiple may be stacked on
top of one another ...

Jan