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>
---
Cc'ing qemu-stable because the regression is present in 2.10.1... :-\
---
target/ppc/compat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/ppc/compat.c b/target/ppc/compat.c
index f8729fe46d61..ad8f93c0644e 100644
--- a/target/ppc/compat.c
+++ b/target/ppc/compat.c
@@ -141,7 +141,7 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp)
cpu_synchronize_state(CPU(cpu));
if (kvm_enabled() && cpu->compat_pvr != compat_pvr) {
- int ret = kvmppc_set_compat(cpu, cpu->compat_pvr);
+ int ret = kvmppc_set_compat(cpu, compat_pvr);
if (ret < 0) {
error_setg_errno(errp, -ret,
"Unable to set CPU compatibility mode in KVM");
On Tue, Oct 17, 2017 at 09:49:14PM +0200, Greg Kurz wrote:
> 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>
Nice catch. Applied to ppc-for-2.11.
> ---
>
> Cc'ing qemu-stable because the regression is present in 2.10.1... :-\
> ---
> target/ppc/compat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/ppc/compat.c b/target/ppc/compat.c
> index f8729fe46d61..ad8f93c0644e 100644
> --- a/target/ppc/compat.c
> +++ b/target/ppc/compat.c
> @@ -141,7 +141,7 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp)
> cpu_synchronize_state(CPU(cpu));
>
> if (kvm_enabled() && cpu->compat_pvr != compat_pvr) {
> - int ret = kvmppc_set_compat(cpu, cpu->compat_pvr);
> + int ret = kvmppc_set_compat(cpu, compat_pvr);
> if (ret < 0) {
> error_setg_errno(errp, -ret,
> "Unable to set CPU compatibility mode in KVM");
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
© 2016 - 2026 Red Hat, Inc.