aboutsummaryrefslogtreecommitdiff
path: root/target/ppc/cpu.h
AgeCommit message (Collapse)Author
2017-03-01target/ppc: Fix KVM-HV HPTE accessorsDavid Gibson
When a 'pseries' guest is running with KVM-HV, the guest's hashed page table (HPT) is stored within the host kernel, so it is not directly accessible to qemu. Most of the time, qemu doesn't need to access it: we're using the hardware MMU, and KVM itself implements the guest hypercalls for manipulating the HPT. However, qemu does need access to the in-KVM HPT to implement get_phys_page_debug() for the benefit of the gdbstub, and maybe for other debug operations. To allow this, 7c43bca "target-ppc: Fix page table lookup with kvm enabled" added kvmppc_hash64_read_pteg() to target/ppc/kvm.c to read in a batch of HPTEs from the KVM table. Unfortunately, there are a couple of problems with this: First, the name of the function implies it always reads a whole PTEG from the HPT, but in fact in some cases it's used to grab individual HPTEs (which ends up pulling 8 HPTEs, not aligned to a PTEG from the kernel). Second, and more importantly, the code to read the HPTEs from KVM is simply wrong, in general. The data from the fd that KVM provides is designed mostly for compact migration rather than this sort of one-off access, and so needs some decoding for this purpose. The current code will work in some cases, but if there are invalid HPTEs then it will not get sane results. This patch rewrite the HPTE reading function to have a simpler interface (just read n HPTEs into a caller provided buffer), and to correctly decode the stream from the kernel. For consistency we also clean up the similar function for altering HPTEs within KVM (introduced in c138593 "target-ppc: Update ppc_hash64_store_hpte to support updating in-kernel htab"). Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-03-01target/ppc: move cpu_[read, write]_xer to cpu.cNikunj A Dadhania
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22target/ppc/POWER9: Adapt LPCR handling for POWER9Suraj Jitindar Singh
The logical partitioning control register controls a threads operation based on the partition it is currently executing. Add new definitions and update the mask used when writing to the LPCR based on the POWER9 spec. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22target/ppc: Fix LPCR DPFD mask defineSuraj Jitindar Singh
The DPFD field in the LPCR is 3 bits wide. This has always been defined as 0x3 << shift which indicates a 2 bit field, which is incorrect. Correct this. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31target/ppc: Add pcr_supported to POWER9 cpu class definitionSuraj Jitindar Singh
pcr_supported is used to define the supported PCR values for a given processor. A POWER9 processor can support 3.00, 2.07, 2.06 and 2.05 compatibility modes, thus we set this accordingly. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31ppc: Add ppc_set_compat_all()David Gibson
Once a compatiblity mode is negotiated with the guest, h_client_architecture_support() uses run_on_cpu() to update each CPU to the new mode. We're going to want this logic somewhere else shortly, so make a helper function to do this global update. We put it in target-ppc/compat.c - it makes as much sense at the CPU level as it does at the machine level. We also move the cpu_synchronize_state() into ppc_set_compat(), since it doesn't really make any sense to call that without synchronizing state. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31ppc: Validate compatibility modes when settingDavid Gibson
Current ppc_set_compat() will attempt to set any compatiblity mode specified, regardless of whether it's available on the CPU. The caller is expected to make sure it is setting a possible mode, which is awkwward because most of the information to make that decision is at the CPU level. This begins to clean this up by introducing a ppc_check_compat() function which will determine if a given compatiblity mode is supported on a CPU (and also whether it lies within specified minimum and maximum compat levels, which will be useful later). It also contains an assertion that the CPU has a "virtual hypervisor"[1], that is, that the guest isn't permitted to execute hypervisor privilege code. Without that, the guest would own the PCR and so could override any mode set here. Only machine types which use a virtual hypervisor (i.e. 'pseries') should use ppc_check_compat(). ppc_set_compat() is modified to validate the compatibility mode it is given and fail if it's not available on this CPU. [1] Or user-only mode, which also obviously doesn't allow access to the hypervisor privileged PCR. We don't use that now, but could in future. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-01-31ppc: Rewrite ppc_get_compat_smt_threads()David Gibson
To continue consolidation of compatibility mode information, this rewrites the ppc_get_compat_smt_threads() function using the table of compatiblity modes in target-ppc/compat.c. It's not a direct replacement, the new ppc_compat_max_threads() function has simpler semantics - it just returns the number of threads the cpu model has, taking into account any compatiblity mode it is in. This no longer takes into account kvmppc_smt_threads() as the previous version did. That check wasn't useful because we check in ppc_cpu_realizefn() that CPUs aren't instantiated with more threads than kvm allows (or if we didn't things will already be broken and this won't make it any worse). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-01-31ppc: Rewrite ppc_set_compat()David Gibson
This rewrites the ppc_set_compat() function so that instead of open coding the various compatibility modes, it reads the relevant data from a table. This is a first step in consolidating the information on compatibility modes scattered across the code into a single place. It also makes one change to the logic. The old code masked the bits to be set in the PCR (Processor Compatibility Register) by which bits are valid on the host CPU. This made no sense, since it was done regardless of whether our guest CPU was the same as the host CPU or not. Furthermore, the actual PCR bits are only relevant for TCG[1] - KVM instead uses the compatibility mode we tell it in kvmppc_set_compat(). When using TCG host cpu information usually isn't even present. While we're at it, we put the new implementation in a new file to make the enormous translate_init.c a little smaller. [1] Actually it doesn't even do anything in TCG, but it will if / when we get to implementing compatibility mode logic at that level. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-01-31ppc: Rename cpu_version to compat_pvrDavid Gibson
The 'cpu_version' field in PowerPCCPU is badly named. It's named after the 'cpu-version' device tree property where it is advertised, but that meaning may not be obvious in most places it appears. Worse, it doesn't even really correspond to that device tree property. The property contains either the processor's PVR, or, if the CPU is running in a compatibility mode, a special "logical PVR" representing which mode. Rename the cpu_version field, and a number of related variables to compat_pvr to make this clearer. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Thomas Huth <thuth@redhat.com>
2017-01-31ppc: Clean up and QOMify hypercall emulationDavid Gibson
The pseries machine type is a bit unusual in that it runs a paravirtualized guest. The guest expects to interact with a hypervisor, and qemu emulates the functions of that hypervisor directly, rather than executing hypervisor code within the emulated system. To implement this in TCG, we need to intercept hypercall instructions and direct them to the machine's hypercall handlers, rather than attempting to perform a privilege change within TCG. This is controlled by a global hook - cpu_ppc_hypercall. This cleanup makes the handling a little cleaner and more extensible than a single global variable. Instead, each CPU to have hypercalls intercepted has a pointer set to a QOM object implementing a new virtual hypervisor interface. A method in that interface is called by TCG when it sees a hypercall instruction. It's possible we may want to add other methods in future. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-01-31target-ppc: add vextu[bhw][lr]x instructionsAvinesh Kumar
vextublx: Vector Extract Unsigned Byte Left vextuhlx: Vector Extract Unsigned Halfword Left vextuwlx: Vector Extract Unsigned Word Left vextubrx: Vector Extract Unsigned Byte Right-Indexed VX-form vextuhrx: Vector Extract Unsigned Halfword Right-Indexed VX-form vextuwrx: Vector Extract Unsigned Word Right-Indexed VX-form Signed-off-by: Avinesh Kumar <avinesku@linux.vnet.ibm.com> Signed-off-by: Hariharan T.S. <hari@linux.vnet.ibm.com> [ implement using int128_rshift ] Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31target-ppc: rename CRF_* defines as CRF_*_BITNikunj A Dadhania
Add _BIT to CRF_[GT,LT,EQ_SO] and introduce CRF_[GT,LT,EQ,SO] for usage without shifts in the code. This would simplify the code. Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-12-20Move target-* CPU file into a target/ folderThomas Huth
We've currently got 18 architectures in QEMU, and thus 18 target-xxx folders in the root folder of the QEMU source tree. More architectures (e.g. RISC-V, AVR) are likely to be included soon, too, so the main folder of the QEMU sources slowly gets quite overcrowded with the target-xxx folders. To disburden the main folder a little bit, let's move the target-xxx folders into a dedicated target/ folder, so that target-xxx/ simply becomes target/xxx/ instead. Acked-by: Laurent Vivier <laurent@vivier.eu> [m68k part] Acked-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> [tricore part] Acked-by: Michael Walle <michael@walle.cc> [lm32 part] Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x part] Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> [s390x part] Acked-by: Eduardo Habkost <ehabkost@redhat.com> [i386 part] Acked-by: Artyom Tarasenko <atar4qemu@gmail.com> [sparc part] Acked-by: Richard Henderson <rth@twiddle.net> [alpha part] Acked-by: Max Filippov <jcmvbkbc@gmail.com> [xtensa part] Reviewed-by: David Gibson <david@gibson.dropbear.id.au> [ppc part] Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> [cris&microblaze part] Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn> [unicore32 part] Signed-off-by: Thomas Huth <thuth@redhat.com>