diff options
| author | David Gibson | 2018-05-01 08:08:50 +0200 |
|---|---|---|
| committer | David Gibson | 2018-05-04 07:00:37 +0200 |
| commit | f00bed9521cee4d67c4937b51de692e0bcf9efef (patch) | |
| tree | db38b9c0f3d4a84144f655695fc3a1097d995e35 /qapi/string-input-visitor.c | |
| parent | spapr: Clean up LPCR updates from hypercalls (diff) | |
| download | qemu-f00bed9521cee4d67c4937b51de692e0bcf9efef.tar.gz qemu-f00bed9521cee4d67c4937b51de692e0bcf9efef.tar.xz qemu-f00bed9521cee4d67c4937b51de692e0bcf9efef.zip | |
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 'qapi/string-input-visitor.c')
0 files changed, 0 insertions, 0 deletions
