Re: [PATCH 3/5] lscpu: detect OS/400 and pHyp hypervisors

Alexander Graf
2014-05-22T09:30:09Z

On 22.05.14 11:08, Heiko Carstens wrote:
> Hi Karel,
>
> I think Alexander Graf (who is kvm on powerpc maintainer) should answer
> how he would like to have it classified.
>
> [full quote below]
>
> On Thu, May 22, 2014 at 10:48:20AM +0200, Karel Zak wrote:
>> Heiko, can you help us to classify pSeries and iSeries virtualization?
>> See below. Is it FULL or PARA virtualization? Thanks!
>>
>> Karel
>>
>> On Thu, May 22, 2014 at 01:03:43AM +0200, Ruediger Meier wrote:
>>>> + [HYPER_OS400] = "OS/400",
>>>> + [HYPER_PHYP] = "pHyp"
>>>> };
>>>>
>>>> const int hv_vendor_pci[] = {
>>>> @@ -574,6 +577,51 @@ read_hypervisor_cpuid(struct lscpu_desc *desc)
>>>> static void
>>>> read_hypervisor_cpuid(struct lscpu_desc *desc __attribute__((__unused__)))
>>>> {
>>>> +#ifdef __powerpc__
>>>> + /* powerpc:
>>>> + * IBM iSeries: legacy, if /proc/iSeries exists, its para-virtualized on top of OS/400
>>> According to this comment ...
>>>
>>>> + * IBM pSeries: always has a hypervisor
>>>> + * if partition-name is "full", its kind of "bare-metal": full-system-partition
>>>> + * otherwise its some partition created by Hardware Management Console
>>>> + * in any case, its always some sort of HVM
>>>> + * KVM: "linux,kvm" in /hypervisor/compatible indicates a KVM guest
>>>> + * Xen: not in use, not detected
>>>> + */
>>>> + if (path_exist("/proc/iSeries")) {
>>>> + desc->hyper = HYPER_OS400;
>>>> + desc->virtype = VIRT_FULL;
>>> ... shouldn't this be VIRT_PARA? Somebody who knows this may correct this.

iSeries is PV, yes. Among others it's also dead :). But I'll let Ben
comment.

>>>
>>>> + } else if (path_exist(_PATH_PROC_DEVICETREE "/ibm,partition-name")) {
>>>> + FILE *fd;
>>>> + desc->hyper = HYPER_PHYP;
>>>> + desc->virtype = VIRT_FULL;
>>> Maybe more obvious here for pSeries where p seems to stand for para
>>> http://www.ibm.com/developerworks/aix/library/au-syspvirtualization/index.html?S_TACT=105AGX99&S_CMP=CP

This is slightly more complicated. The ibm,partition-name device tree
property is defined in sPAPR which is a specification that both pHyp and
QEMU implement. Right now QEMU does not expose the ibm,partition-name
property, but there's no reason it will stay that way.

There are a few ways we could try to distinguish QEMU's implementation
of the pSeries machine and pHyp's implementation of it.

/proc/device-tree/hmc-managed?

I don't think QEMU will ever implement this property, but at least my
pHyp reference VM does. If it's there we can use it as a definite marker
that we are in fact running on pHyp.

/proc/device-tree/chosen/qemu,graphic-width

Only QEMU puts qemu, properties in the chosen directory. At least the
current code always sets the graphic-* properties, so if we find one we
can safely assume we're running on QEMU. We do not know whether we're
running on KVM yet.

Checking on KVM is slightly more tricky. I think we have 2 options:

1) Check if /proc/device-tree/cpus/*@0/timebase-frequency is 1000000000.

If it is, we're emulated (no KVM). If it's not, we're running with
a native CPU (KVM).

2) Check whether /proc/device-tree/hypervisor/compatible == "linux,kvm"

I have a patch in my queue to make the sPAPR compliant pSeries
machine type in QEMU also ePAPR compliant and expose a /hypervisor node.
Current versions of QEMU don't do this though, so this would not catch
QEMU versions < 2.1.

The nice thing about the ePAPR compliant check is that we'd catch
non-pSeries machine types as well. We expose this node on all emulated
Mac machines and on FSL e500 style machines.

Alex