ppc/spapr: Use start-powered-off CPUState property
commit554c2169e9251ca2829ab968bd9ba5641a5abe1d
authorThiago Jung Bauermann <bauerman@linux.ibm.com>
Wed, 26 Aug 2020 05:55:30 +0000 (26 02:55 -0300)
committerDavid Gibson <david@gibson.dropbear.id.au>
Tue, 8 Sep 2020 00:08:43 +0000 (8 10:08 +1000)
tree6372516d8119f09e8e5c8c7cfe5e34d8e58f7278
parent6ad1da667c8e21f019d4adc21702e06dd9225790
ppc/spapr: Use start-powered-off CPUState property

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>
hw/ppc/spapr_cpu_core.c