Bug#1038901: xen dom0 erroneous detected as 'xen' virtualization by systemd-detect-virt

[Maximilian Engelhardt]

Package: systemd
Version: 252.6-1
Severity: normal
X-Debbugs-Cc: ma...@daemonizer.de
Control: affects -1 + src:xen

When running the xen hypervisor, systemd-detect-virt erroneous detects 'xen'
virtualization on the dom0:

$ systemd-detect-virt
xen

The expected output should be 'none', in case of a dom0 with no other
virtualization. The documentation [1] says 'xen' corresponds to "Xen
hypervisor (only domU, not dom0)".

Here is some more debug output in the hope it will be helpful:

On a dom0 (detect wrongly):
$ SYSTEMD_LOG_LEVEL=debug systemd-detect-virt
Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
Found container virtualization none.
No virtualization found in DMI vendor table.
DMI BIOS Extension table does not indicate virtualization.
UML virtualization not found in /proc/cpuinfo.
Virtualization XEN found (/proc/xen exists)
Virtualization XEN, found /sys/hypervisor/properties/features with value 000228f0, XENFEAT_dom0 (indicating the 'hardware domain') is set.
Virtualization found, CPUID=XenVMMXenVMM
Found VM virtualization xen
xen

On a domU (detected correctly):
$ SYSTEMD_LOG_LEVEL=debug systemd-detect-virt
Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
Found container virtualization none.
No virtualization found in DMI vendor table.
Unable to read /sys/firmware/dmi/entries/0-0/raw, using the virtualization information found in DMI vendor table, ignoring: No such file or directory
UML virtualization not found in /proc/cpuinfo.
Virtualization XEN found (/proc/xen exists)
Virtualization XEN, found /sys/hypervisor/properties/features with value 00012305, XENFEAT_dom0 (indicating the 'hardware domain') is not set.
Found VM virtualization xen
xen

XENFEAT_dom0 seems to be detected correctly in both cases, but the dom0 has
one additional line which is not present in the domU output:
Virtualization found, CPUID=XenVMMXenVMM

This behavior is especially a problem since the smartmontools service file has
"ConditionVirtualization=no" and thus does not get started on the dom0.

This problem might be related to the upstream bug [2], but the symptoms are a
bit different.

[1] https://manpages.debian.org/bookworm/systemd/systemd-detect-virt.1.en.html
[2] https://github.com/systemd/systemd/issues/28113

[Michael Biebl]

Am 22.06.23 um 23:04 schrieb Maximilian Engelhardt:

> Package: systemd
> Version: 252.6-1
> Severity: normal
> X-Debbugs-Cc: ma...@daemonizer.de
> Control: affects -1 + src:xen
>
> When running the xen hypervisor, systemd-detect-virt erroneous detects 'xen'
> virtualization on the dom0:

Thanks for your bug report.
Please consider filing this issue upstream or following up on the issue
you mentioned in [2].


commit ea583ed5a366cf51b80bd363db95e828a25ec27e
Author: Richard Neill <richar...@arm.com>
Date: Wed Feb 2 18:18:46 2022 +0000

virt: Fix Xen Dom0 detection logic to no longer report as VM


https://github.com/systemd/systemd/commit/ea583ed5a366cf51b80bd363db95e828a25ec27e

appears to be relevant here as well

[zithro]

Hello,

I reported the bug upstream, just added there some comments to reflect
that the output is different on AMD and Intel platforms.
I also added the commit link, thanks for that.

So, "systemd-detect-virt" on non-nested dom0s reports :
- "xen" on Intel (like this bug report)
- "vm-other" on AMD (like my bug report upstream)

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/systemd/issues/28113

Am 23.06.23 um 18:14 schrieb zithro:

Ok, let's mark https://github.com/systemd/systemd/issues/28113 as the
relevant upstream bug report.