e4f0c6bb1a
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> |
||
---|---|---|
.. | ||
alpha | ||
arm | ||
cris | ||
hppa | ||
i386 | ||
lm32 | ||
m68k | ||
microblaze | ||
mips | ||
moxie | ||
nios2 | ||
openrisc | ||
ppc | ||
s390x | ||
sh4 | ||
sparc | ||
tilegx | ||
tricore | ||
unicore32 | ||
xtensa |