diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2018-05-01 16:08:50 +1000 |
---|---|---|
committer | David Gibson <david@gibson.dropbear.id.au> | 2018-05-04 15:00:37 +1000 |
commit | f00bed9521cee4d67c4937b51de692e0bcf9efef (patch) | |
tree | db38b9c0f3d4a84144f655695fc3a1097d995e35 /target/ppc/cpu.h | |
parent | 295b6c26aca97c5f6f6609f62d958af6af848454 (diff) | |
download | qemu-f00bed9521cee4d67c4937b51de692e0bcf9efef.zip qemu-f00bed9521cee4d67c4937b51de692e0bcf9efef.tar.gz qemu-f00bed9521cee4d67c4937b51de692e0bcf9efef.tar.bz2 |
target/ppc: Delay initialization of LPCR_UPRT for secondary cpus
In cpu_ppc_set_papr() the UPRT and GTSE bits of the LPCR default value are
initialized based on on ppc64_radix_guest(). Which seems reasonable,
except that ppc64_radix_guest() is based on spapr->patb_entry which is
only set up in spapr_machine_reset, called _after_ cpu_ppc_set_papr() for
boot cpus. Well, and the fact that modifying the SPR default value for an
instance rather than a class is kind of yucky.
The initialization here is really only necessary or valid for
hotplugged cpus; the base cpu initialization already sets a value
that's good enough for the boot cpus until the guest uses an hcall to
configure it's preferred MMU mode.
So, move this initialization to the rtas_start_cpu() path, at which point
ppc64_radix_guest() will have a sensible value, to make sure secondary cpus
come up in an MMU mode matching the existing cpus.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Cédric Le Goater <clg@kaod.org>
Diffstat (limited to 'target/ppc/cpu.h')
0 files changed, 0 insertions, 0 deletions