Documentation/Platforms/POWER

This page lists some information about running POWER Linux guests with QEMU (aka. sPAPR / pSeries / System p guests). You can select this machine type by running qemu-system-ppc64 with the "-M pseries" option (or simply omit the machine option since it is currently the default for the qemu-system-ppc64 binary).

sPAPR devices

The sPAPR specification defines a set of para-virtualized devices, which are also supported by the pseries machine in QEMU and can be instantiated with the -device option:

• spapr-vlan : A virtual network interface
• spapr-vscsi : A virtual SCSI disk interface
• spapr-rng : A pseudo-device for passing random number generator data to the guest (see the H_RANDOM hypercall feature for details)

However, since these devices have originally been specified with another hypervisor and non-Linux guests in mind, you should use the virtio counterparts (virtio-net, virtio-blk/scsi and virtio-rng) if possible instead, since they might give you much better performance with Linux guests.

The pseries machine in QEMU is always instantiated with a NVRAM device ("spapr-nvram"), so you don't have to add this manually. However, if you want to make the contents of the NVRAM device persistent, you've got to specify a PFLASH device when starting QEMU, i.e. either use -drive if=pflash,file=filename,format=raw to set the default PFLASH device, or specify one with an ID (-drive if=none,file=filename,format=raw,id=pfid) and pass that ID to the NVRAM device with -global spapr-nvram.drive=pfid.

Switching between the KVM-PR and KVM-HV kernel module

Currently, there are two implementations of KVM on POWER, kvm_hv.ko and kvm_pr.ko:

1. KVM-PR:
   • Uses the so-called "PRoblem state" of the ppc CPUs to run the guests, i.e. the VM is run in user mode and all privileged instructions trap and have to be emulated by the host.
   • Guests that use a lot of privileged instructions are running quite slow this way...
   • ... but the benefit is that this kernel module should run on pretty much every PPC hardware, and is able to emulate a lot of guest CPUs.
   • Can also be used to run other PowerPC guests like an emulated PowerMac.
   • Can be used for nested virtualization (i.e. running a guest from within a guest)
2. KVM-HV:
   • Requires hardware support of modern POWER server CPUs (like the recent POWER7/POWER8 CPUs).
   • Can only be used to run sPAPR (pseries) guests.
   • Guests that use a lot of privileged instructions are running much faster than with KVM-PR.
   • The guest CPU has to be of the same type as the host CPU this way (e.g. you can not specify an embedded PPC CPU for the guest with KVM-HV). However, there is at least the possibility to run the guest in a backward-compatibility mode of the previous CPU generation, e.g. you can run a POWER7 guest on a POWER8 host by using "-cpu POWER8,compat=power7" as parameter to QEMU.
   • Can not be used for nested virtualization (but you can still run the kvm-pr kernel module in a kvm-hv guest to get nested virtualization)

If your host supports both KVM modes, and both KVM kernel modules are loaded, you can switch between the two modes with the "kvm-type" parameter:

• Use "qemu-system-ppc64 -M pseries,kvm-type=PR" to use the kvm_pr.ko kernel module.
• Use "qemu-system-ppc64 -M pseries,kvm-type=HV" to use kvm_hv.ko instead.

Links

• Linux on Power Architecture Platform Reference specification