aboutsummaryrefslogtreecommitdiff
path: root/target/ppc
AgeCommit message (Collapse)AuthorFilesLines
2018-06-27compiler: add a sizeof_field() macroStefan Hajnoczi1-5/+5
Determining the size of a field is useful when you don't have a struct variable handy. Open-coding this is ugly. This patch adds the sizeof_field() macro, which is similar to typeof_field(). Existing instances are updated to use the macro. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20180614164431.29305-1-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-06-22spapr: Don't rewrite mmu capabilities in KVM modeDavid Gibson2-68/+70
Currently during KVM initialization on POWER, kvm_fixup_page_sizes() rewrites a bunch of information in the cpu state to reflect the capabilities of the host MMU and KVM. This overwrites the information that's already there reflecting how the TCG implementation of the MMU will operate. This means that we can get guest-visibly different behaviour between KVM and TCG (and between different KVM implementations). That's bad. It also prevents migration between KVM and TCG. The pseries machine type now has filtering of the pagesizes it allows the guest to use which means it can present a consistent model of the MMU across all accelerators. So, we can now replace kvm_fixup_page_sizes() with kvm_check_mmu() which merely verifies that the expected cpu model can be faithfully handled by KVM, rather than updating the cpu model to match KVM. We call kvm_check_mmu() from the spapr cpu reset code. This is a hack: conceptually it makes more sense where fixup_page_sizes() was - in the KVM cpu init path. However, doing that would require moving the platform's pagesize filtering much earlier, which would require a lot of work making further adjustments. There wouldn't be a lot of concrete point to doing that, since the only KVM implementation which has the awkward MMU restrictions is KVM HV, which can only work with an spapr guest anyway. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2018-06-22target/ppc: Add ppc_hash64_filter_pagesizes()David Gibson2-0/+62
The paravirtualized PAPR platform sometimes needs to restrict the guest to using only some of the page sizes actually supported by the host's MMU. At the moment this is handled in KVM specific code, but for consistency we want to apply the same limitations to all accelerators. This makes a start on this by providing a helper function in the cpu code to allow platform code to remove some of the cpu's page size definitions via a caller supplied callback. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-06-22spapr: Use maximum page size capability to simplify memory backend checkingDavid Gibson2-20/+0
The way we used to handle KVM allowable guest pagesizes for PAPR guests required some convoluted checking of memory attached to the guest. The allowable pagesizes advertised to the guest cpus depended on the memory which was attached at boot, but then we needed to ensure that any memory later hotplugged didn't change which pagesizes were allowed. Now that we have an explicit machine option to control the allowable maximum pagesize we can simplify this. We just check all memory backends against that declared pagesize. We check base and cold-plugged memory at reset time, and hotplugged memory at pre_plug() time. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-06-21target/ppc: Add missing opcode for icbt on PPC440BALATON Zoltan1-0/+2
According to PPC440 User Manual PPC440 has multiple opcodes for icbt instruction: one for compatibility with older cores and two 440 specific opcodes one of which is defined in BookE. QEMU only implements two of these, add the missing one. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-06-21fpu_helper.c: fix helper_fpscr_clrbit() functionJohn Arbuckle1-0/+28
Fix the helper_fpscr_clrbit() function so it correctly sets the FEX and VX bits. Determining the value for the Floating Point Status and Control Register's (FPSCR) FEX bit is suppose to be done like this: FEX = (VX & VE) | (OX & OE) | (UX & UE) | (ZX & ZE) | (XX & XE)) It is described as "the logical OR of all the floating-point exception bits masked by their respective enable bits". It was not implemented correctly. The value of FEX would stay on even when all other bits were set to off. The VX bit is described as "the logical OR of all of the invalid operation exceptions". This bit was also not implemented correctly. It too would stay on when all the other bits were set to off. My main source of information is an IBM document called: PowerPC Microprocessor Family: The Programming Environments for 32-Bit Microprocessors Page 62 is where the FPSCR information is located. This is an older copy than the one I use but it is still very useful: https://www.pdfdrive.net/powerpc-microprocessor-family-the-programming-environments-for-32-e3087633.html I use a G3 and G5 iMac to compare bit values with QEMU. This patch fixed all the problems I was having with these bits. Signed-off-by: John Arbuckle <programmingkidx@gmail.com> [dwg: Re-wrapped commit message] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-06-21target/ppc: Add kvmppc_hpt_needs_host_contiguous_pages() helperDavid Gibson2-2/+21
KVM HV has a restriction that for HPT mode guests, guest pages must be hpa contiguous as well as gpa contiguous. We have to account for that in various places. We determine whether we're subject to this restriction from the SMMU information exposed by KVM. Planned cleanups to the way we handle this will require knowing whether this restriction is in play in wider parts of the code. So, expose a helper function which returns it. This does mean some redundant calls to kvm_get_smmu_info(), but they'll go away again with future cleanups. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2018-06-21target/ppc: Allow cpu compatiblity checks based on type, not instanceDavid Gibson2-6/+25
ppc_check_compat() is used in a number of places to check if a cpu object supports a certain compatiblity mode, subject to various constraints. It takes a PowerPCCPU *, however it really only depends on the cpu's class. We have upcoming cases where it would be useful to make compatibility checks before we fully instantiate the cpu objects. ppc_type_check_compat() will now make an equivalent check, but based on a CPU's QOM typename instead of an instantiated CPU object. We make use of the new interface in several places in spapr, where we're essentially making a global check, rather than one specific to a particular cpu. This avoids some ugly uses of first_cpu to grab a "representative" instance. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2018-06-16target/ppc, spapr: Move VPA information to machine_dataDavid Gibson3-32/+22
CPUPPCState currently contains a number of fields containing the state of the VPA. The VPA is a PAPR specific concept covering several guest/host shared memory areas used to communicate some information with the hypervisor. As a PAPR concept this is really machine specific information, although it is per-cpu, so it doesn't really belong in the core CPU state structure. There's also other information that's per-cpu, but platform/machine specific. So create a (void *)machine_data in PowerPCCPU which can be used by the machine to locate per-cpu data. Intialization, lifetime and cleanup of machine_data is entirely up to the machine type. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org>
2018-06-16target/ppc: drop empty #if/#endif blockGreg Kurz1-2/+0
Commit 9d6f106552fa moved the last line in this block to somewhere else, but it forgot to remove the now useless #if/#endif. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-06-16target/ppc: Don't require private l1d cache on POWER8 for cap_ppc_safe_cacheSuraj Jitindar Singh1-1/+18
For cap_ppc_safe_cache to be set to workaround, we require both a l1d cache flush instruction and private l1d cache. On POWER8 don't require private l1d cache. This means a guest on a POWER8 machine can make use of the cache flush workarounds. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-06-12target/ppc: Allow PIR read in privileged modeluporl1-1/+1
According to PowerISA, the PIR register should be readable in privileged mode also, not only in hypervisor privileged mode. PowerISA 3.0 - 4.3.3 Processor Identification Register "Read access to the PIR is privileged; write access is not provided." Figure 18 in section 4.4.4 explicitly confirms that mfspr PIR is privileged and doesn't require hypervisor state. Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Alexander Graf <agraf@suse.de> Cc: qemu-ppc@nongnu.org Signed-off-by: Leandro Lupori <leandro.lupori@gmail.com> Reviewed-by: Jose Ricardo Ziviani <joserz@linux.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-06-12target/ppc: extend eieio for POWER9Cédric Le Goater1-2/+23
POWER9 introduced a new variant of the eieio instruction using bit 6 as a hint to tell the CPU it is a store-forwarding barrier. The usage of this eieio extension was recently added in Linux 4.17 which activated the "support for a store forwarding barrier at kernel entry/exit". Unfortunately, it is not possible to insert this new eieio instruction without considerable change in ppc_tr_translate_insn(). So instead we loosen the QEMU eieio instruction mask and modify the gen_eieio() helper to test for bit6. On non-POWER9 CPUs, the bit6 is just ignored but a warning is emitted as this is not an instruction software should be using. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-06-12target/ppc: Allow privileged access to SPR_PCRJoel Stanley3-2/+17
The powerpc Linux kernel[1] and skiboot firmware[2] recently gained changes that cause the Processor Compatibility Register (PCR) SPR to be cleared. These changes cause Linux to fail to boot on the Qemu powernv machine with an error: Trying to write privileged spr 338 (0x152) at 0000000030017f0c With this patch Qemu makes this register available as a hypervisor privileged register. Note that bits set in this register disable features of the processor. Currently the only register state that is supported is when the register is zeroed (enable all features). This is sufficient for guests to once again boot. [1] https://lkml.kernel.org/r/20180518013742.24095-1-mikey@neuling.org [2] https://patchwork.ozlabs.org/patch/915932/ Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-06-12target/ppc: Factor out the parsing in kvmppc_get_cpu_characteristics()Suraj Jitindar Singh1-20/+39
Factor out the parsing of struct kvm_ppc_cpu_char in kvmppc_get_cpu_characteristics() into a separate function for each cap for simplicity. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-06-12target/ppc: Use proper logging function for possible guest errorsThomas Huth1-25/+12
fprintf() and qemu_log_separate() are frowned upon these days for printing logging information in QEMU. Accessing the wrong SPRs indicates wrong guest behaviour in most cases, and we've got a proper way to log such situations, which is the qemu_log_mask(LOG_GUEST_ERROR, ...) function. So use this function now for logging the bad SPR accesses instead. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-06-04Merge remote-tracking branch 'remotes/rth/tags/tcg-next-pull-request' into ↵Peter Maydell1-2/+2
staging tcg-next queue # gpg: Signature made Sat 02 Jun 2018 00:12:42 BST # gpg: using RSA key 64DF38E8AF7E215F # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" # Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F * remotes/rth/tags/tcg-next-pull-request: tcg: Pass tb and index to tcg_gen_exit_tb separately Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-06-01tcg: Pass tb and index to tcg_gen_exit_tb separatelyRichard Henderson1-2/+2
Do the cast to uintptr_t within the helper, so that the compiler can type check the pointer argument. We can also do some more sanity checking of the index argument. Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2018-06-01Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell2-1/+1
* Linux header upgrade (Peter) * firmware.json definition (Laszlo) * IPMI migration fix (Corey) * QOM improvements (Alexey, Philippe, me) * Memory API cleanups (Jay, me, Tristan, Peter) * WHPX fixes and improvements (Lucian) * Chardev fixes (Marc-André) * IOMMU documentation improvements (Peter) * Coverity fixes (Peter, Philippe) * Include cleanup (Philippe) * -clock deprecation (Thomas) * Disable -sandbox unless CONFIG_SECCOMP (Yi Min Zhao) * Configurability improvements (me) # gpg: Signature made Fri 01 Jun 2018 17:42:13 BST # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (56 commits) hw: make virtio devices configurable via default-configs/ hw: allow compiling out SCSI memory: Make operations using MemoryRegionIoeventfd struct pass by pointer. char: Remove unwanted crlf conversion qdev: Remove DeviceClass::init() and ::exit() qdev: Simplify the SysBusDeviceClass::init path hw/i2c: Use DeviceClass::realize instead of I2CSlaveClass::init hw/i2c/smbus: Use DeviceClass::realize instead of SMBusDeviceClass::init target/i386/kvm.c: Remove compatibility shim for KVM_HINTS_REALTIME Update Linux headers to 4.17-rc6 target/i386/kvm.c: Handle renaming of KVM_HINTS_DEDICATED scripts/update-linux-headers: Handle kernel license no longer being one file scripts/update-linux-headers: Handle __aligned_u64 virtio-gpu-3d: Define VIRTIO_GPU_CAPSET_VIRGL2 elsewhere gdbstub: Prevent fd leakage docs/interop: add "firmware.json" ipmi: Use proper struct reference for KCS vmstate vmstate: Add a VSTRUCT type tcg: remove softfloat from --disable-tcg builds qemu-options: Mark the non-functional -clock option as deprecated ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-06-01target: Do not include "exec/exec-all.h" if it is not necessaryPhilippe Mathieu-Daudé1-1/+0
Code change produced with: $ git grep '#include "exec/exec-all.h"' | \ cut -d: -f-1 | \ xargs egrep -L "(cpu_address_space_init|cpu_loop_|tlb_|tb_|GETPC|singlestep|TranslationBlock)" | \ xargs sed -i.bak '/#include "exec\/exec-all.h"/d' Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180528232719.4721-10-f4bug@amsat.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-05-31target/ppc: Include "exec/exec-all.h" which provides tlb_flush()Philippe Mathieu-Daudé1-0/+1
Since it inception this include uses tlb_flush() declared in "exec/exec-all.h". Include the other header to allow further includes cleanup. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180528232719.4721-8-f4bug@amsat.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-05-31Make address_space_map() take a MemTxAttrs argumentPeter Maydell1-1/+2
As part of plumbing MemTxAttrs down to the IOMMU translate method, add MemTxAttrs as an argument to address_space_map(). Its callers either have an attrs value to hand, or don't care and can use MEMTXATTRS_UNSPECIFIED. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180521140402.23318-5-peter.maydell@linaro.org
2018-05-29ppc: Rename 2.13 machines to 3.0Peter Maydell3-6/+6
Rename the 2.13 machines to match the number we're going to use for the next release. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-id: 20180522104000.9044-5-peter.maydell@linaro.org
2018-05-18target/ppc: Honor CPU_DUMP_FPURichard Henderson1-7/+13
Cc: Alexander Graf <agraf@suse.de> Cc: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2018-05-17fpu/softfloat: Specialize on snan_bit_is_oneRichard Henderson1-1/+0
Only MIPS requires snan_bit_is_one to be variable. While we are specializing softfloat behaviour, allow other targets to eliminate this runtime check. Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: Yongbok Kim <yongbok.kim@mips.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Alexander Graf <agraf@suse.de> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn> Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2018-05-14Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell4-3/+2
* Don't silently truncate extremely long words in the command line * dtc configure fixes * MemoryRegionCache second try * Deprecated option removal * add support for Hyper-V reenlightenment MSRs # gpg: Signature made Fri 11 May 2018 13:33:46 BST # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (29 commits) rename included C files to foo.inc.c, remove osdep.h pc-dimm: fix error messages if no slots were defined build: Silence dtc directory creation shippable: Remove Debian 8 libfdt kludge configure: Display if libfdt is from system or git configure: Really use local libfdt if the system one is too old i386/kvm: add support for Hyper-V reenlightenment MSRs qemu-doc: provide details of supported build platforms qemu-options: Remove deprecated -no-kvm-irqchip qemu-options: Remove deprecated -no-kvm-pit-reinjection qemu-options: Bail out on unsupported options instead of silently ignoring them qemu-options: Remove remainders of the -tdf option qemu-options: Mark -virtioconsole as deprecated target/i386: sev: fix memory leaks opts: don't silently truncate long option values opts: don't silently truncate long parameter keys accel: use g_strsplit for parsing accelerator names update-linux-headers: drop hyperv.h qemu-thread: always keep the posix wrapper layer exec: reintroduce MemoryRegion caching ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-05-11rename included C files to foo.inc.c, remove osdep.hPaolo Bonzini4-3/+2
osdep.h is only needed for files that are compiled directly. Remove it from included C source files, and rename them to *.inc.c so that scripts/clean-includes knows to skip them. Cc: Eric Blake <eblake@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-05-09translator: merge max_insns into DisasContextBaseEmilio G. Cota1-3/+2
While at it, use int for both num_insns and max_insns to make sure we have same-type comparisons. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Michael Clark <mjc@sifive.com> Signed-off-by: Emilio G. Cota <cota@braap.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2018-05-04Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2018-05-04' into ↵Peter Maydell1-1/+1
staging QAPI patches for 2018-05-04 # gpg: Signature made Fri 04 May 2018 08:59:16 BST # gpg: using RSA key 3870B400EB918653 # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-qapi-2018-05-04: qapi: deprecate CpuInfoFast.arch qapi: discriminate CpuInfoFast on SysEmuTarget, not CpuInfoArch qapi: change the type of TargetInfo.arch from string to enum SysEmuTarget qapi: add SysEmuTarget to "common.json" qapi: fill in CpuInfoFast.arch in query-cpus-fast qobject: Modify qobject_ref() to return obj qobject: Replace qobject_incref/QINCREF qobject_decref/QDECREF qobject: use a QObjectBase_ struct qobject: Ensure base is at offset 0 qobject: Use qobject_to() instead of type cast Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-05-04qobject: Replace qobject_incref/QINCREF qobject_decref/QDECREFMarc-André Lureau1-1/+1
Now that we can safely call QOBJECT() on QObject * as well as its subtypes, we can have macros qobject_ref() / qobject_unref() that work everywhere instead of having to use QINCREF() / QDECREF() for QObject and qobject_incref() / qobject_decref() for its subtypes. The replacement is mechanical, except I broke a long line, and added a cast in monitor_qmp_cleanup_req_queue_locked(). Unlike qobject_decref(), qobject_unref() doesn't accept void *. Note that the new macros evaluate their argument exactly once, thus no need to shout them. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20180419150145.24795-4-marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Rebased, semantic conflict resolved, commit message improved] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-05-04target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hackGreg Kurz1-0/+5
The pseries-2.7 and older machine types require CPUPPCState::insns_flags to be strictly equal between source and destination. This checking is abusive and breaks migration of KVM guests when the host CPU models are different, even if they are compatible enough to allow the guest to run transparently. This buggy behaviour was fixed for pseries-2.8 and we added some hacks to allow backward migration of older machine types. These hacks assume that the CPU belongs to the POWER8 family, which was true for most KVM based setup we cared about at the time. But now POWER9 systems are coming, and backward migration of pre 2.8 guests running in POWER8 architected mode from a POWER9 host to a POWER8 host is broken: qemu-system-ppc64: error while loading state for instance 0x0 of device 'cpu' qemu-system-ppc64: load of migration failed: Invalid argument This happens because POWER9 doesn't set PPC_MEM_TLBIE in insns_flags, while POWER8 does. Let's force PPC_MEM_TLBIE in the migration hack to fix the issue. This is an acceptable hack because these old machine types only support CPU models that do set PPC_MEM_TLBIE. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-05-04spapr: Move PAPR mode cpu setup fully to spapr codeDavid Gibson3-42/+6
cpu_ppc_set_papr() does several things: 1) it sets up the virtual hypervisor interface 2) it prevents the cpu from ever entering hypervisor mode 3) it tells KVM that we're emulating a cpu in PAPR mode and 4) it configures the LPCR and AMOR (hypervisor privileged registers) so that TCG will behave correctly for PAPR guests, without attempting to emulate the cpu in hypervisor mode (1) & (2) make sense for any virtual hypervisor (if another one ever exists). (3) belongs more properly in the machine type specific to a PAPR guest, so move it to spapr_cpu_init(). While we're at it, remove an ugly test on kvm_enabled() by making kvmppc_set_papr() a safe no-op on non-KVM. (4) also belongs more properly in the machine type specific code. (4) is done by mangling the default values of the SPRs, so that they will be set correctly at reset time. Manipulating usually-static parameters of the cpu model like this is kind of ugly, especially since the values used really have more to do with the platform than the cpu. The spapr code already has places for PAPR specific initializations of register state in spapr_cpu_reset(), so move this handling there. 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>
2018-05-04target/ppc: Delay initialization of LPCR_UPRT for secondary cpusDavid Gibson1-16/+0
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>
2018-05-04target/ppc: Add ppc_store_lpcr() helperDavid Gibson3-11/+13
There are some fields in the cpu state which need to be updated when the LPCR register is changed, which is done by ppc_hash64_update_rmls() and ppc_hash64_update_vrma(). Code which alters env->spr[SPR_LPCR] needs to call them afterwards to make sure the state is up to date. That's easy to get wrong. The normal way of dealing with sitautions like that is to use a helper which both updates the basic register value and the derived state. So, do that. 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> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-05-04spapr: Remove support for explicitly allocated RMAsDavid Gibson2-48/+0
Current POWER cpus allow for a VRMA, a special mapping which describes a guest's view of memory when in real mode (MMU off, from the guest's point of view). Older cpus didn't have that which meant that to support a guest a special host-contiguous region of memory was needed to give the guest its Real Mode Area (RMA). KVM used to provide special calls to allocate a contiguous RMA for those cases. This was useful in the early days of KVM on Power to allow it to be tested on PowerPC 970 chips as used in Macintosh G5 machines. Now, those machines are so old as to be almost irrelevant. The normal qemu deprecation process would require this to be marked deprecated then removed in 2 releases. However, this can only be used with corresponding support in the host kernel - which was dropped years ago (in c17b98cf "KVM: PPC: Book3S HV: Remove code for PPC970 processors" of 2014-12-03 to be precise). Therefore it should be ok to drop this immediately. Just to be clear this only affects *KVM HV* guests with PowerPC 970, and those already require an ancient host kernel. TCG and KVM PR guests with PowerPC 970 should still work. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Thomas Huth <thuth@redhat.com>
2018-05-04target/ppc: add basic support for PTCR on POWER9Cédric Le Goater7-0/+71
The Partition Table Control Register (PTCR) is a hypervisor privileged SPR. It contains the host real address of the Partition Table and its size. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-05-04target/ppc: return a nil HPT base address on sPAPR machinesCédric Le Goater1-0/+3
commit e57ca75ce3b2 ("target/ppc: Manage external HPT via virtual hypervisor") exported a set of methods to manipulate the HPT from the core hash MMU. But SPR_SDR1 is still used under some circumstances to get the base address of the HPT, which is incorrect for the sPAPR machines. Only the logging should be impacted. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-04-27target/ppc: Don't bother with MSR_EP in cpu_ppc_set_papr()David Gibson1-5/+4
cpu_ppc_set_papr() removes the EP and HV bits from the MSR mask. While removing the HV bit makes sense (a cpu in PAPR mode should never be emulated in hypervisor mode), the EP bit is just bizarre. Although it's true that a papr mode guest shouldn't be able to change the exception prefix, the MSR[EP] bit doesn't even exist on the cpus supported for PAPR mode, so it's pointless to do anything with it here. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com>
2018-04-27target/ppc: Fold slb_nr into PPCHash64OptionsDavid Gibson6-26/+35
The env->slb_nr field gives the size of the SLB (Segment Lookaside Buffer). This is another static-after-initialization parameter of the specific version of the 64-bit hash MMU in the CPU. So, this patch folds the field into PPCHash64Options with the other hash MMU options. This is a bit more complicated that the things previously put in there, because slb_nr was foolishly included in the migration stream. So we need some of the usual dance to handle backwards compatible migration. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-04-27target/ppc: Get rid of POWERPC_MMU_VER() macrosDavid Gibson5-34/+28
These macros were introduced to deal with the fact that the mmu_model field has bit flags mixed in with what's otherwise an enum of various mmu types. We've now eliminated all those flags except for one, and that one - POWERPC_MMU_64 - is already included/compared in the MMU_VER macros. So, we can get rid of those macros and just directly compare mmu_model values in the places it was used. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-04-27target/ppc: Remove unnecessary POWERPC_MMU_V3 flag from mmu_modelDavid Gibson2-4/+2
The only place we test this flag is in conjunction with ppc64_use_proc_tbl(). That checks for the LPCR_UPRT bit, which we already ensure can't be set except on a machine with a v3 MMU (i.e. POWER9). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-04-27target/ppc: Fold ci_large_pages flag into PPCHash64OptionsDavid Gibson5-6/+7
The ci_large_pages boolean in CPUPPCState is only relevant to 64-bit hash MMU machines, indicating whether it's possible to map large (> 4kiB) pages as cache-inhibitied (i.e. for IO, rather than memory). Fold it as another flag into the PPCHash64Options structure. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-04-27target/ppc: Move 1T segment and AMR options to PPCHash64OptionsDavid Gibson4-12/+17
Currently env->mmu_model is a bit of an unholy mess of an enum of distinct MMU types, with various flag bits as well. This makes which bits of the field should be compared pretty confusing. Make a start on cleaning that up by moving two of the flags bits - POWERPC_MMU_1TSEG and POWERPC_MMU_AMR - which are specific to the 64-bit hash MMU into a new flags field in PPCHash64Options structure. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-04-27target/ppc: Make hash64_opts field mandatory for 64-bit hash MMUsDavid Gibson3-18/+21
Currently some cpus set the hash64_opts field in the class structure, with specific details of their variant of the 64-bit hash mmu. For the remaining cpus with that mmu, ppc_hash64_realize() fills in defaults. But there are only a couple of cpus that use those fallbacks, so just have them to set the has64_opts field instead, simplifying the logic. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-04-27target/ppc: Split page size information into a separate allocationDavid Gibson6-75/+78
env->sps contains page size encoding information as an embedded structure. Since this information is specific to 64-bit hash MMUs, split it out into a separately allocated structure, to reduce the basic env size for other cpus. Along the way we make a few other cleanups: * Rename to PPCHash64Options which is more in line with qemu name conventions, and reflects that we're going to merge some more hash64 mmu specific details in there in future. Also rename its substructures to match qemu conventions. * Move structure definitions to the mmu-hash64.[ch] files. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2018-04-27target/ppc: Move page size setup to helper functionDavid Gibson3-20/+49
Initialization of the env->sps structure at the end of instance_init is specific to the 64-bit hash MMU, so move the code into a helper function in mmu-hash64.c. We also create a corresponding function to be called at finalize time - it's empty for now, but we'll need it shortly. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-04-27target/ppc: Remove fallback 64k pagesize informationDavid Gibson3-29/+2
CPU definitions for cpus with the 64-bit hash MMU can include a table of available pagesizes. If this isn't supplied ppc_cpu_instance_init() will fill it in a fallback table based on the POWERPC_MMU_64K bit in mmu_model. However, it turns out all the cpus which support 64K pages already include an explicit table of page sizes, so there's no point to the fallback table including 64k pages. That removes the only place which tests POWERPC_MMU_64K, so we can remove it. Which in turn allows some logic to be removed from kvm_fixup_page_sizes(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-04-27target/ppc: Avoid taking "env" parameter to mmu-hash64 functionsDavid Gibson3-20/+23
In most cases we prefer to pass a PowerPCCPU rather than the (embedded) CPUPPCState. For ppc_hash64_update_{rmls,vrma}() change to take "cpu" instead of "env". For ppc_hash64_set_{dsi,isi}() remove the redundant "env" parameter. In theory this makes more work for the functions, but since "cs", "cpu" and "env" are related by at most constant offsets, the compiler should be able to optimize out the difference at effectively zero cost. helper_*() functions are left alone - since they're more closely tied to the TCG generated code, passing "env" is still the standard there. While we're there, fix an incorrect indentation. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2018-04-27target/ppc: Simplify cpu valid check in ppc_cpu_realizeDavid Gibson1-8/+1
The #if isn't necessary, because there's a suitable one inside ppc_cpu_is_valid(). We've already filtered for suitable cpu models in the functions that search and register them. So by the time we get to realize having an invalid one indicates a code error, not a user error, so an assert() is more appropriate than error_setg(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-04-27target/ppc: Standardize instance_init and realize function namesDavid Gibson1-6/+6
Because of the various hooks called some variant on "init" - and the rather greater number that used to exist, I'm always wondering when a function called simply "*_init" or "*_initfn" will be called. To make it easier on myself, and maybe others, rename the instance_init hooks for ppc cpus to *_instance_init(). While we're at it rename the realize time hooks to *_realize() (from *_realizefn()) which seems to be the more common current convention. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>