diff options
| author | David Gibson <david@gibson.dropbear.id.au> | 2016-11-16 13:54:48 +1100 |
|---|---|---|
| committer | David Gibson <david@gibson.dropbear.id.au> | 2017-01-31 10:10:14 +1100 |
| commit | 152ef803ceb1959e2380a1da7736b935b109222e (patch) | |
| tree | b70903c557334dd1149de261e9dbe5052b3ae73e /target/ppc/cpu.h | |
| parent | ef291226494f53f10c5cbe90bff550a52bda7b76 (diff) | |
| download | qemu-152ef803ceb1959e2380a1da7736b935b109222e.zip qemu-152ef803ceb1959e2380a1da7736b935b109222e.tar.gz qemu-152ef803ceb1959e2380a1da7736b935b109222e.tar.bz2 | |
pseries: Rewrite CAS PVR compatibility logic
During boot, PAPR guests negotiate CPU model support with the
ibm,client-architecture-support mechanism. The logic to implement this in
qemu is very convoluted. This cleans it up to be cleaner, using the new
ppc_check_compat() call.
The new logic for choosing a compatibility mode is:
1. Usually, use the most recent compatibility mode that is
a) supported by the guest
b) supported by the CPU
and c) no later than the maximum allowed (if specified)
2. If no suitable compatibility mode was found, the guest *does*
support this CPU explicitly, and no maximum compatibility mode is
specified, then use "raw" mode for the current CPU
3. Otherwise, fail the boot.
This differs from the results of the old code: the old code preferred using
"raw" mode to a compatibility mode, whereas the new code prefers a
compatibility mode if available. Using compatibility mode preferentially
means that we're more likely to be able to migrate the guest to a similar
but not identical host.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'target/ppc/cpu.h')
0 files changed, 0 insertions, 0 deletions