target-ppc: Add "compat" CPU option

PowerISA defines a compatibility mode for server POWERPC CPUs which
is supported by the PCR special register which is hypervisor privileged.
To support this mode for guests, SPAPR defines a set of virtual PVRs,
one per PowerISA spec version. When a hypervisor needs a guest to work in
a compatibility mode, it puts a virtual PVR value into @cpu-version
property of a CPU node.

This introduces a "compat" CPU option which defines maximal compatibility
mode enabled. The supported modes are power6/power7/power8.

This does not change the existing behaviour, new property will be used
by next patches.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
spapr: Move SMT-related properties out of skeleton fdt

The upcoming support of the "ibm,client-architecture-support"
reconfiguration call will be able to change dynamically the number
of threads per core (SMT mode). From the device tree prospective
this does not change the number of CPU nodes (as it is one node per
a CPU core) but affects content and size of the ibm,ppc-interrupt-server#s
and ibm,ppc-interrupt-gserver#s properties.

This moves ibm,ppc-interrupt-server#s and ibm,ppc-interrupt-gserver#s
out of the device tree skeleton.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
target-ppc: Implement "compat" CPU option

This adds basic support for the "compat" CPU option. By specifying
the compat property, the user can manually switch guest CPU mode from
"raw" to "architected".

This defines feature disable bits which are not used yet as, for example,
PowerISA 2.07 says if 2.06 mode is selected, the TM bit does not matter -
transactional memory (TM) will be disabled because 2.06 does not define
it at all. The same is true for VSX and 2.05 mode. So just setting a mode
must be ok.

This does not change the existing behavior as the actual compatibility
mode support is coming in next patches.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
target-ppc: Define Processor Compatibility Masks

This introduces PCR mask for supported compatibility modes.
This will be used later by the ibm,client-architecture-support call.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
spapr: Add ibm, client-architecture-support call

The PAPR+ specification defines a ibm,client-architecture-support (CAS)
RTAS call which purpose is to provide a negotiation mechanism for
the guest and the hypervisor to work out the best compatibility parameters.
During the negotiation process, the guest provides an array of various
options and capabilities which it supports, the hypervisor adjusts
the device tree and (optionally) reboots the guest.

At the moment the Linux guest calls CAS method at early boot so SLOF
gets called. SLOF allocates a memory buffer for the device tree changes
and calls a custom KVMPPC_H_CAS hypercall. QEMU parses the options,
composes a diff for the device tree, copies it to the buffer provided
by SLOF and returns to SLOF. SLOF updates the device tree and returns
control to the guest kernel. Only then the Linux guest parses the device
tree so it is possible to avoid unnecessary reboot in most cases.

The device tree diff is a header with an update format version
(defined as 1 in this patch) followed by a device tree with the properties
which require update.

If QEMU detects that it has to reboot the guest, it silently does so
as the guest expects reboot to happen because this is usual pHyp firmware
behavior.

This defines custom KVMPPC_H_CAS hypercall. The current SLOF already
has support for it.

This implements stub which returns very basic tree (root node,
no properties) to the guest.

As the return buffer does not contain any change, no change in behavior is
expected.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
spapr: Rework spapr_fixup_cpu_dt()

In PPC code we usually use the "cs" name for a CPUState* variables
and "cpu" for PowerPCCPU. So let's change spapr_fixup_cpu_dt() to
use same rules as spapr_create_fdt_skel() does.

This adds missing nodes creation if they do not already exist in
the current device tree, this is going to be used from
the client-architecture-support handler.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
spapr: Limit threads per core according to current compatibility mode

This puts a limit to the number of threads per core based on the current
compatibility mode. Although PowerISA specs do not specify the maximum
threads per core number, the linux guest still expects that
PowerISA2.05-compatible CPU supports only 2 threads per core as this
is what POWER6 (2.05 compliant CPU) implements, the same is for
POWER7 (2.06, 4 threads) and POWER8 (2.07, 8 threads).

This calls spapr_fixup_cpu_smt_dt() with the maximum allowed number of
threads which affects ibm,ppc-interrupt-server#s and
ibm,ppc-interrupt-gserver#s properties.

The number of CPU nodesremains unchanged.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
spapr: Implement processor compatibility in ibm, client-architecture-support

Modern Linux kernels support last POWERPC CPUs so when a kernel boots,
in most cases it can find a matching cpu_spec in the kernel's cpu_specs
list. However if the kernel is quite old, it may be missing a definition
of the actual CPU. To provide an ability for old kernels to work on modern
hardware, a Processor Compatibility Mode has been introduced
by the PowerISA specification.

>From the hardware prospective, it is supported by the Processor
Compatibility Register (PCR) which is defined in PowerISA. The register
enables one of the compatibility modes (2.05/2.06/2.07).
Since PCR is a hypervisor privileged register and cannot be
directly accessed from the guest, the mode selection is done via
ibm,client-architecture-support (CAS) RTAS call using which the guest
specifies what "raw" and "architected" CPU versions it supports.
QEMU works out the best match, changes a "cpu-version" property of
every CPU and notifies the guest about the change by setting these
properties in the buffer passed as a response on a custom H_CAS hypercall.

This implements ibm,client-architecture-support parameters parsing
(now only for PVRs) and cooks the device tree diff with new values for
"cpu-version", "ibm,ppc-interrupt-server#s" and
"ibm,ppc-interrupt-server#s" properties.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
KVM: PPC: Enable compatibility mode

The host kernel implements a KVM_REG_PPC_ARCH_COMPAT register which
this uses to enable a compatibility mode if any chosen.

This sets the KVM_REG_PPC_ARCH_COMPAT register in KVM. ppc_set_compat()
signals the caller if the mode cannot be enabled by the host kernel.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[agraf: fix TCG compat setting]
Signed-off-by: Alexander Graf <agraf@suse.de>
spapr_iommu: Replace @instance_id with LIOBN for migration

SPAPR IOMMU is a bus-less device and therefore its only ID in
migration stream is an instance id which is not reliable ID
as it depends on the command line parameters order. Since
libvirt may change the order, we need something better than that.

This removes VMSD descriptor from the class definitiion and
registers it with @liobn as an intance ID to let the destination
side find the right device to receive migration data.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
PPC: Fix popcntb opcode id

The popcntb opcode is at 31/122 according to the spec. In QEMU's internal
opcode representation that sums up to 1f/1a/03.

Fix the opcode definition to match on the correct ID.

This fixes booting Linux with -cpu POWER7,compat=power6 in TCG mode for me.

Signed-off-by: Alexander Graf <agraf@suse.de>
macio ide: Do remainder access asynchronously

The macio IDE controller has some pretty nasty magic in its implementation to
allow for unaligned sector accesses. We used to handle these accesses
synchronously inside the IO callback handler.

However, the block infrastructure changed below our feet and now it's impossible
to call a synchronous block read/write from the aio callback handler of a
previous block access.

Work around that limitation by making the unaligned handling bits also go
through our asynchronous handler.

This fixes booting Mac OS X for me.

Reported-by: John Arbuckle <programmingkidx@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
target-ppc: Rename 7XX/60x/74XX/e600 PMU SPRs

As defined in Linux kernel, PMC*, SIAR, MMCR0/1 have different numbers
for 32 and 64 bit POWERPC. We are going to support 64bit versions too so
let's rename 32bit ones to avoid confusion.

This is a mechanical patch so it does not fix obvious mistake with these
registers in POWER7 yet, this will be fixed later.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
target-ppc: Merge 970FX and 970MP into a single 970 class

The differences between classes were:
1. SLB size, was 32 for 970 and 64 for others, should be 64 for all;
2. check_pow() callback, HID0 format is the same so should be the same
0x01C00000 which means "deep nap", "doze" and "nap" bits set;
3. LPCR - 970 does not have it but 970MP had one (by mistake).

This fixes wrong differences and makes one 970 class.

This fixes wrong registration of LPCR which is not present on 970.

This does not remove check_pow_970FX now as it is still used by POWER5+
class, this will be addressed later.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
target-ppc: Refactor PPC970

This splits one init_proc_970() into a set of small helpers. Later
init_proc_970() will be generalized and will call different set of helpers
depending on the current CPU class.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
target-ppc: Copy and split gen_spr_7xx() for 970

This stops using 7xx common SPRs init function and adds separate set
of helpers for 970.

This does not copy ICTC SPR as neither 970 manual nor PowerISA mention it.

This defines 970/book3s PMU SPRs constants as they differs from the ones
used for 7XX.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
target-ppc: Add "POWER" prefix to MMCRA PMU registers

Since we started adding "POWER" prefix to 64bit PMU SPRs, let's finish
the transition and fix MMCRA and define a hypv version of it.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
target-ppc: Add PMC5/6, SDAR and MMCRA to 970 family

MMCR0, MMCR1, MMCRA, PMC1..6, SIAR, SDAR are defined for 970 and PowerISA
CPUs. Since we are building common infrastructure for SPRs intialization
to share it between 970 and POWER5+/7/..., let's add missing SPRs to
the 970 family. Later rework of CPU class initialization will use those
for all PowerISA CPUs.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
target-ppc: Add PMC7/8 to 970 class

Compared to PowerISA-compliant CPUs, 970 family has most of them plus
PMC7/8 which are only present on 970 but not on POWER5 and later CPUs.

Since we are changing SPRs for Book3s/970 families, let's add them too.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
target-ppc: Add HID4 SPR for PPC970

Previously LPCR was registered for the 970 class which was wrong as
it does not have LPCR. Instead, HID4 is used which this patch registers.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>