qemu-kvm/kvm-ppc-spapr-Use-start-powered-off-CPUState-property.patch
Danilo C. L. de Paula 7b68902699 * Tue Sep 15 2020 Danilo Cesar Lemes de Paula <ddepaula@redhat.com> - 5.1.0-7.el8
- kvm-target-ppc-Add-experimental-option-for-enabling-secu.patch [bz#1789757 bz#1870384]
- kvm-target-arm-Move-start-powered-off-property-to-generi.patch [bz#1849483]
- kvm-target-arm-Move-setting-of-CPU-halted-state-to-gener.patch [bz#1849483]
- kvm-ppc-spapr-Use-start-powered-off-CPUState-property.patch [bz#1849483]
- Resolves: bz#1789757
  ([IBM 8.4 FEAT] Add machine option to enable secure VM support)
- Resolves: bz#1849483
  (Failed to boot up guest when hotplugging vcpus on bios stage)
- Resolves: bz#1870384
  ([IBM 8.3 FEAT] Add interim/unsupported machine option to enable secure VM support for testing purposes)
2020-09-15 11:56:35 -04:00

83 lines
3.3 KiB
Diff

From 5dd7cdf3739c73d910d5df6443b39e9b0b79f3fd Mon Sep 17 00:00:00 2001
From: Laurent Vivier <lvivier@redhat.com>
Date: Tue, 8 Sep 2020 18:47:16 -0400
Subject: [PATCH 4/4] ppc/spapr: Use start-powered-off CPUState property
RH-Author: Laurent Vivier <lvivier@redhat.com>
Message-id: <20200908184716.1125192-4-lvivier@redhat.com>
Patchwork-id: 98302
O-Subject: [RHEL-AV-8.3.0 qemu-kvm PATCH 3/3] ppc/spapr: Use start-powered-off CPUState property
Bugzilla: 1849483
RH-Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
RH-Acked-by: David Gibson <dgibson@redhat.com>
RH-Acked-by: Greg Kurz <gkurz@redhat.com>
From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
PowerPC sPAPR CPUs start in the halted state, and spapr_reset_vcpu()
attempts to implement this by setting CPUState::halted to 1. But that's too
late for the case of hotplugged CPUs in a machine configure with 2 or more
threads per core.
By then, other parts of QEMU have already caused the vCPU to run in an
unitialized state a couple of times. For example, ppc_cpu_reset() calls
ppc_tlb_invalidate_all(), which ends up calling async_run_on_cpu(). This
kicks the new vCPU while it has CPUState::halted = 0, causing QEMU to issue
a KVM_RUN ioctl on the new vCPU before the guest is able to make the
start-cpu RTAS call to initialize its register state.
This problem doesn't seem to cause visible issues for regular guests, but
on a secure guest running under the Ultravisor it does. The Ultravisor
relies on being able to snoop on the start-cpu RTAS call to map vCPUs to
guests, and this issue causes it to see a stray vCPU that doesn't belong to
any guest.
Fix by setting the start-powered-off CPUState property in
spapr_create_vcpu(), which makes cpu_common_reset() initialize
CPUState::halted to 1 at an earlier moment.
Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Message-Id: <20200826055535.951207-4-bauerman@linux.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 554c2169e9251ca2829ab968bd9ba5641a5abe1d)
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
---
hw/ppc/spapr_cpu_core.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
index f228f8bb75..86fed5c528 100644
--- a/hw/ppc/spapr_cpu_core.c
+++ b/hw/ppc/spapr_cpu_core.c
@@ -37,11 +37,6 @@ static void spapr_reset_vcpu(PowerPCCPU *cpu)
cpu_reset(cs);
- /* All CPUs start halted. CPU0 is unhalted from the machine level
- * reset code and the rest are explicitly started up by the guest
- * using an RTAS call */
- cs->halted = 1;
-
env->spr[SPR_HIOR] = 0;
lpcr = env->spr[SPR_LPCR];
@@ -287,6 +282,11 @@ static PowerPCCPU *spapr_create_vcpu(SpaprCpuCore *sc, int i, Error **errp)
cs = CPU(obj);
cpu = POWERPC_CPU(obj);
+ /*
+ * All CPUs start halted. CPU0 is unhalted from the machine level reset code
+ * and the rest are explicitly started up by the guest using an RTAS call.
+ */
+ cs->start_powered_off = true;
cs->cpu_index = cc->core_id + i;
spapr_set_vcpu_id(cpu, cs->cpu_index, &local_err);
if (local_err) {
--
2.27.0