lscpu (from util-linux) contains virt detection code for PPC

[root@ibm-power7r2-01-le02 ~]# lscpu
Architecture:          ppc64le
Byte Order:            Little Endian
CPU(s):                16
On-line CPU(s) list:   0-15
Thread(s) per core:    4
Core(s) per socket:    1
Socket(s):             4
NUMA node(s):          1
Model:                 IBM pSeries (emulated by qemu)
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
NUMA node0 CPU(s):     0-15
[root@ibm-power7r2-01-le02 ~]# rpm -q util-linux
util-linux-2.25.1-0.1.fc21.ppc64le

https://github.com/karelzak/util-linux/commit/5bd31c6d6e1e77c2843505601ee6cbb58ac74e9c

There is something weird. I think that mentioned patch from util-linux would not work on rhel7.

It looks that 
/proc/device-tree/hypervisor/compatible
is present only with newest kernel which is in f21

So the real question here is what do you want "virt" to mean in the context of this systemd test.

Any ppc64 system that shows platform "pSeries" (rather than "PowerNV") is (para)virtualized - and always has been - either under PowerVM or PowerKVM.  This includes every power system we've supported for a decade or so.

Yes, there is no hypervisor/ directory on 3.10.0-131.el7.ppc64, but it seems the file is in top level device tree directory:

# cat /proc/device-tree/compatible 
qemu,pseries

.. I guess it should be enough.

If I good understand IBM pSeries always has a hypervisor, but pSeries could be also emulated by qemu. IMHO the qemu version is what we're talking about. I don't see the /proc/devices-tree/hypervisor/ also on 3.14.5-200.fc20.ppc64p7, so it's no specific to old (rhel) kernels.

So, some background.  powerpc kernels have a notion of "platform" which indicates the hardware &firmware environment the kernel is running in - it can be physical, para)virtual or some combination.  The platform is displayed at the bottom of the /proc/cpuinfo output.

Platform "pSeries" indicates the kernel is running in the paravirtualized environment described by the PAPR+ document (POWER Architecture Platform Requirements.  That environment could be provided either by PowerVM (IBM's proprietary hypervisor, aka pHyp) or (recently) by qemu.  I don't know what systemd wants the virtualization info for, so I don't know whether it matters to it whether it's qemu or PowerVM - for most purposes it shouldn't matter.

If the kernel is running "bare metal" on POWER, "pSeries" hardware, it will have platform "PowerNV" (for POWER Non-Virtualized).  This isn't supported in RHEL (though it will mostly work), but we're working towards limited support in 7.2 for use as a RHEV hypervisor.

/proc/device-tree exposes the device tree information supplied by that platform firmware, so it's contents depend on the firmware, not the (guest) kernel.

Incidentally, that lscpu patch looks wrong - running under KVM on POWER is no more "full virtualization" than running under pHyp - they're both providing basically the same PAPR+ virtual environment.

Thanks David, so if I good understand than in devices tree:

 * /ibm,partition-name means pHyp (according the lscpu Suse patch)
 * /compatible = ibm,powernv  means powerNV (bare metal)
 * /compatible = qemu,pseries means qemu

the Suse patch also checks for /hypervisor/compatible, but it seems line nonsense or some legacy, right?

Note that for systemd it's probably unimportant, but for lscpu(1) it would be nice to provide all the information (hypervisor type).

Please, review
https://github.com/karelzak/util-linux/blob/master/sys-utils/lscpu.c#L621

Karel,

I think it is safer to first check for "Platform: PowerNV" in /proc/cpuinfo to detect the powernv case before checking /proc/device-tree.  The device tree is supplied by firmware, and might contain unexpected things depending on the exact firmware version.  cpuinfo is produced by the kernel and if it's not right more important things will be broken anyway.

Your patch appears to treat the PowerNV case as being KVM virtualized, which is not correct.  PowerNV == "POWER Non Virtualized", so it should be 

The test for pHyp vs KVM is probably right: because KVM implements the same paravirt interface as pHyp, there's no defined way to tell the difference, it's just a question of which (generally unimportant) properties happen to be implemented in pHyp but not qemu/KVM.

I note that there is a test for the case of a full-system partition under pHyp.  Non-virtualized full system partitions only exist on ancient POWER4 machines.  Newer machines have something called "full system partitions" but they're still para-virtualized just like any other partition.  I'm not sure if they will show up in the same way in the device tree though.

Ah... the thing with PowerNV is copy & paste mistake (work on conferences is probably bad idea ;-)

I'm not sure with the Power4, this code is originally from Suse, I guess they had some machines where it makes sense. I'll try to ask them for more details.

Thanks!

Works now after rebase:
[lnykryn@ibm-p8-generic-01-le02 ~]$ systemd-detect-virt
none
[lnykryn@ibm-p8-generic-01-le02 ~]$ systemd-detect-virt --version
systemd 208
+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ
[lnykryn@ibm-p8-generic-01-le02 ~]$ usr/bin/systemd-detect-virt --version
systemd 219
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN
[lnykryn@ibm-p8-generic-01-le02 ~]$ usr/bin/systemd-detect-virt
kvm

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2092.html