ppc: fix setting of compat mode
commite4f0c6bb1a9f72ad9e32c3171d36bae17ea1cd67
authorGreg Kurz <groug@kaod.org>
Tue, 17 Oct 2017 19:49:14 +0000 (17 21:49 +0200)
committerDavid Gibson <david@gibson.dropbear.id.au>
Wed, 8 Nov 2017 02:21:37 +0000 (8 13:21 +1100)
treeebc9bdf1ed4afd40d266ba8bf68711125c1c819c
parentb0fbe46ad82982b289a44ee2495b59b0bad8a842
ppc: fix setting of compat mode

While trying to make KVM PR usable again, commit 5dfaa532ae introduced a
regression: the current compat_pvr value is passed to KVM instead of the
new one. This means that we always pass 0 instead of the max-cpu-compat
PVR during the initial machine reset. And at CAS time, we either pass
the PVR from the command line or even don't call kvmppc_set_compat() at
all, ie, the PCR will not be set as expected.

For example if we start a big endian fedora26 guest in power7 compat
mode on a POWER8 host, we get this in the guest:

$ cat /proc/cpuinfo
processor       : 0
cpu             : POWER7 (architected), altivec supported
clock           : 4024.000000MHz
revision        : 2.0 (pvr 004d 0200)

timebase        : 512000000
platform        : pSeries
model           : IBM pSeries (emulated by qemu)
machine         : CHRP IBM pSeries (emulated by qemu)
MMU             : Hash

but the guest can still execute POWER8 instructions, and the following
program succeeds:

int main()
{
        asm("vncipher 0,0,0"); // ISA 2.07 instruction
}

Let's pass the new compat_pvr to kvmppc_set_compat() and the program fails
with SIGILL as expected.

Reported-by: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
target/ppc/compat.c