summary refs log tree commit diff stats
path: root/hw/ppc/spapr_cpu_core.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* spapr: fix the value of SDR1 in kvmppc_put_books_sregs()Greg Kurz2017-09-271-15/+1
| | | | | | | | | | | | | | | | | | | | | When running with KVM PR, if a new HPT is allocated we need to inform KVM about the HPT address and size. This is currently done by hacking the value of SDR1 and pushing it to KVM in several places. Also, migration breaks the guest since it is very unlikely the HPT has the same address in source and destination, but we push the incoming value of SDR1 to KVM anyway. This patch introduces a new virtual hypervisor hook so that the spapr code can provide the correct value of SDR1 to be pushed to KVM each time kvmppc_put_books_sregs() is called. It allows to get rid of all the hacking in the spapr/kvmppc code and it fixes migration of nested KVM PR. Suggested-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr_cpu_core: cleaning up qdev_get_machine() callsGreg Kurz2017-09-151-3/+3
| | | | | | | | | | | | | This patch removes the qdev_get_machine() calls that are made in spapr_cpu_core.c in situations where we can get an existing pointer for the MachineState by either passing it as an argument to the function or by using other already available pointers. Credits to Daniel Henrique Barboza for the idea and the changelog text. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr_cpu_core: fail gracefully with non-pseries machine typesGreg Kurz2017-09-151-2/+3
| | | | | | | | | | | | Since commit 7cca3e466eb0 ("ppc: spapr: Move VCPU ID calculation into sPAPR"), QEMU aborts when started with a *-spapr-cpu-core device and a non-pseries machine. Let's rely on the already existing call to object_dynamic_cast() instead of using the SPAPR_MACHINE() macro. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc: spapr: Move VCPU ID calculation into sPAPRSam Bobroff2017-09-081-0/+11
| | | | | | | | | | | | | | Move the calculation of a CPU's VCPU ID out of the generic PPC code (ppc_cpu_realizefn()) and into sPAPR specific code (spapr_cpu_core_realize()) where it belongs. Unfortunately, due to the way things are ordered, we still need to default the VCPU ID in ppc_cpu_realizfn() but at least doing that doesn't require any interaction with sPAPR. Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc: make cpu_model translation to type consistentIgor Mammedov2017-09-081-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PPC handles -cpu FOO rather incosistently, i.e. it does case-insensitive matching of FOO to a CPU type (see: ppc_cpu_compare_class_name) but handles alias names as case-sensitive, as result: # qemu-system-ppc64 -M mac99 -cpu g3 qemu-system-ppc64: unable to find CPU model ' kN�U' # qemu-system-ppc64 -cpu 970MP_V1.1 qemu-system-ppc64: Unable to find sPAPR CPU Core definition while # qemu-system-ppc64 -M mac99 -cpu G3 # qemu-system-ppc64 -cpu 970MP_v1.1 start up just fine. Considering we can't take case-insensitive matching away, make it case-insensitive for all alias/type/core_type lookups. As side effect it allows to remove duplicate core types which are the same except of using different cased letters in name. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* hw/ppc/spapr_cpu_core: Add a proper check for spapr machineThomas Huth2017-09-081-0/+5
| | | | | | | | | | | | | | | | | | QEMU currently crashes when the user tries to add a spapr-cpu-core on a non-pseries machine: $ qemu-system-ppc64 -S -machine ppce500,accel=tcg \ -device POWER5+_v2.1-spapr-cpu-core hw/ppc/spapr_cpu_core.c:178:spapr_cpu_core_realize_child: Object 0x55cee1f55160 is not an instance of type spapr-machine Aborted (core dumped) So let's add a proper check for the correct machine time with a more friendly error message here. Reported-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: prevent QEMU crash when CPU realization failsBharata B Rao2017-06-301-3/+4
| | | | | | | | | | | | | | | ICPState objects were being allocated before CPU thread realization. However commit 9ed656631d73 (xics: setup cpu at realize time) reversed it by allocating ICPState objects after CPU thread is realized. But it didn't take care to fix the error path because of which we observe a SIGSEGV when CPU thread realization fails during cold/hotplug. Fix this by ensuring that we do object_unparent() of ICPState object only in case when is was created earlier. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* pseries: Reset CPU compatibility modeDavid Gibson2017-06-301-10/+0
| | | | | | | | | | | | | | | | | | Currently, the CPU compatibility mode is set when the cpu is initialized, then again when the guest negotiates features. This means if a guest negotiates a compatibility mode, then reboots, that compatibility mode will be retained across the reset. Usually that will get overridden when features are negotiated on the next boot, but it's still not really correct. This patch moves the initial set up of the compatibility mode from cpu init to reset time. The mode *is* retained if the reboot was caused by the feature negotiation (it might be important in that case, though it's unlikely). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Tested-by: Andrea Bolognani <abologna@redhat.com>
* pseries: Move CPU compatibility property to machineDavid Gibson2017-06-301-2/+53
| | | | | | | | | | | | | | | | | | | | | | | Server class POWER CPUs have a "compat" property, which is used to set the backwards compatibility mode for the processor. However, this only makes sense for machine types which don't give the guest access to hypervisor privilege - otherwise the compatibility level is under the guest's control. To reflect this, this removes the CPU 'compat' property and instead creates a 'max-cpu-compat' property on the pseries machine. Strictly speaking this breaks compatibility, but AFAIK the 'compat' option was never (directly) used with -device or device_add. The option was used with -cpu. So, to maintain compatibility, this patch adds a hack to the cpu option parsing to strip out any compat options supplied with -cpu and set them on the machine property instead of the now deprecated cpu property. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org> Tested-by: Andrea Bolognani <abologna@redhat.com>
* xics: setup cpu at realize timeGreg Kurz2017-06-091-13/+10
| | | | | | | | | | | | | | | | | | | | | Until recently, spapr used to allocate ICPState objects for the lifetime of the machine. They would only be associated to vCPUs in xics_cpu_setup() when plugging a CPU core. Now that ICPState objects have the same lifecycle as vCPUs, it is possible to associate them during realization. This patch hence open-codes xics_cpu_setup() in icp_realize(). The vCPU is passed as a property. Note that vCPU now needs to be realized first for the IRQs to be allocated. It also needs to resetted before ICPState realization in order to synchronize with KVM. Since ICPState objects are freed when unrealized, xics_cpu_destroy() isn't needed anymore and can be safely dropped. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* xics: introduce macros for ICP/ICS link propertiesGreg Kurz2017-06-091-1/+2
| | | | | | | | These properties are part of the XICS API. They deserve to appear explicitely in the XICS header file. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* numa: move numa_node from CPUState into target specific classesIgor Mammedov2017-06-051-1/+3
| | | | | | | | | | | Move vcpu's associated numa_node field out of generic CPUState into inherited classes that actually care about cpu<->numa mapping, i.e: ARMCPU, PowerPCCPU, X86CPU. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1496161442-96665-6-git-send-email-imammedo@redhat.com> [ehabkost: s/CPU is belonging to/CPU belongs to/ on comments] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* spapr_cpu_core: drop reference on ICP object during CPU realizationGreg Kurz2017-05-241-1/+2
| | | | | | | | | | | | | | When a piece of code allocates an object, it implicitely gets a reference on it. If it then makes that object a child property of another object, it should drop its own reference at some point otherwise the child object can never be finalized. The current code hence leaks one ICP object per CPU when hot-removing a core. Failing to add a newly allocated ICP object to the CPU is a bug. While here, let's ensure QEMU aborts if this ever happens. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr-cpu-core: release ICP object when realization failsGreg Kurz2017-05-241-8/+8
| | | | | | | While here we introduce a single error path to avoid code duplication. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: get numa node mapping from possible_cpus instead of ↵Igor Mammedov2017-05-111-12/+2
| | | | | | | | | | | | | numa_get_node_for_cpu() it's safe to remove thread node_id != core node_id error branch as machine_set_cpu_numa_node() also does mismatch check and is called even before any CPU is created. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <1494415802-227633-10-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* spapr: add node-id property to sPAPR coreIgor Mammedov2017-05-111-3/+8
| | | | | | | | | | it will allow switching from cpu_index to core based numa mapping in follow up patches. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <1494415802-227633-3-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* spapr-cpu-core: Release ICPState object during CPU unrealizationBharata B Rao2017-04-261-0/+1
| | | | | | | | | | Recent commits that re-organized ICPState object missed to destroy the object when CPU is unrealized. Fix this so that CPU unplug doesn't abort QEMU. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: allocate the ICPState object from under sPAPRCPUCoreCédric Le Goater2017-04-261-4/+14
| | | | | | | | | | | | | | | | | | | | Today, all the ICPs are created before the CPUs, stored in an array under the sPAPR machine and linked to the CPU when the core threads are realized. This modeling brings some complexity when a lookup in the array is required and it can be simplified by allocating the ICPs when the CPUs are. This is the purpose of this proposal which introduces a new 'icp_type' field under the machine and creates the ICP objects of the right type (KVM or not) before the PowerPCCPU object are. This change allows more cleanups : the removal of the icps array under the sPAPR machine and the removal of the xics_get_cpu_index_by_dt_id() helper. 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>
* spapr: move the IRQ server number mapping under the machineCédric Le Goater2017-04-261-1/+1
| | | | | | | | | | | This is the second step to abstract the IRQ 'server' number of the XICS layer. Now that the prereq cleanups have been done in the previous patch, we can move down the 'cpu_dt_id' to 'cpu_index' mapping in the sPAPR machine handler. 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>
* ppc/xics: introduce an 'intc' backlink under PowerPCCPUCédric Le Goater2017-04-261-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Today, the ICPState array of the sPAPR machine is indexed with 'cpu_index' of the CPUState. This numbering of CPUs is internal to QEMU and the guest only knows about what is exposed in the device tree, that is the 'cpu_dt_id'. This is why sPAPR uses the helper xics_get_cpu_index_by_dt_id() to do the mapping in a couple of places. To provide a more generic XICS layer, we need to abstract the IRQ 'server' number and remove any assumption made on its nature. It should not be used as a 'cpu_index' for lookups like xics_cpu_setup() and xics_cpu_destroy() do. To reach that goal, we choose to introduce a generic 'intc' backlink under PowerPCCPU, and let the machine core init routine do the ICPState lookup. The resulting object is passed on to xics_cpu_setup() which does the store under PowerPCCPU. The IRQ 'server' number in XICS is now generic. sPAPR uses 'cpu_dt_id' and PowerNV will use 'PIR' number. This also has the benefit of simplifying the sPAPR hcall routines which do not need to do any ICPState lookups anymore. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: ensure that all threads within core are on the same NUMA nodeIgor Mammedov2017-03-061-8/+15
| | | | | | | | | | | | | | | | | | | Threads within a core shouldn't be on different NUMA nodes, so if user has misconfgured command line, fail QEMU at start up to force user fix it. For now use the first thread on the core as source of core's node-id. Later when cpu-numa refactoring lands it will be switched to core's node-id from possible_cpus[]. This prevents the same problems as commit 20bb648d "spapr: Fix default NUMA node allocation for threads", but for the case of manually configured NUMA node mappings, instead of just the default case. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* hw/ppc/spapr: Add POWER9 to pseries cpu modelsSuraj Jitindar Singh2017-03-031-0/+3
| | | | | | | | | | | | | Add POWER9 cpu to list of spapr core models which allows it to be specified as the cpu model for a pseries guest (e.g. -machine pseries -cpu POWER9). This now allows a POWER9 cpu to boot to userspace in tcg emulation for a pseries machine with a legacy kernel. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Balbir Singh <bsingharora@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/xics: use the QOM interface to grab an ICPCédric Le Goater2017-03-011-2/+2
| | | | | | | Also introduce a xics_icp_get() helper to simplify the changes. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* target/ppc: Manage external HPT via virtual hypervisorDavid Gibson2017-03-011-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The pseries machine type implements the behaviour of a PAPR compliant hypervisor, without actually executing such a hypervisor on the virtual CPU. To do this we need some hooks in the CPU code to make hypervisor facilities get redirected to the machine instead of emulated internally. For hypercalls this is managed through the cpu->vhyp field, which points to a QOM interface with a method implementing the hypercall. For the hashed page table (HPT) - also a hypervisor resource - we use an older hack. CPUPPCState has an 'external_htab' field which when non-NULL indicates that the HPT is stored in qemu memory, rather than within the guest's address space. For consistency - and to make some future extensions easier - this merges the external HPT mechanism into the vhyp mechanism. Methods are added to vhyp for the basic operations the core hash MMU code needs: map_hptes() and unmap_hptes() for reading the HPT, store_hpte() for updating it and hpt_mask() to retrieve its size. To match this, the pseries machine now sets these vhyp fields in its existing vhyp class, rather than reaching into the cpu object to set the external_htab field. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
* target/ppc: Merge cpu_ppc_set_vhyp() with cpu_ppc_set_papr()David Gibson2017-03-011-2/+1
| | | | | | | | | | | cpu_ppc_set_papr() sets up various aspects of CPU state for use with PAPR paravirtualized guests. However, it doesn't set the virtual hypervisor, so callers must also call cpu_ppc_set_vhyp() so that PAPR hypercalls are handled properly. This is a bit silly, so fold setting the virtual hypervisor into cpu_ppc_set_papr(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
* spapr: move spapr_core_[foo]plug() callbacks close to machine code in spapr.cIgor Mammedov2017-02-221-138/+0
| | | | | | | | | | | spapr_core_pre_plug/spapr_core_plug/spapr_core_unplug() are managing wiring CPU core into spapr machine state and not internal CPU core state. So move them from spapr_cpu_core.c to spapr.c where other similar (spapr_memory_[foo]plug()) callbacks are located, which also matches x86 target practice. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: cpu core: separate child threads destruction from machine state ↵Igor Mammedov2017-02-221-5/+10
| | | | | | | | | | | | | | | | | | operations Split off destroying VCPU threads from drc callback spapr_core_release() into new spapr_cpu_core_unrealizefn() which takes care of internal cpu core state cleanup (i.e. VCPU threads) and is called when object_unparent(core) is called. That leaves spapr_core_release() only with board mgmt code, which will be moved to board related file in follow up patch along with the rest on hotplug callbacks. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc: Clean up and QOMify hypercall emulationDavid Gibson2017-01-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
* pseries: Always use core objects for CPU constructionDavid Gibson2017-01-311-18/+19
| | | | | | | | | | | | | | | | | | | | | Currently the pseries machine has two paths for constructing CPUs. On newer machine type versions, which support cpu hotplug, it constructs cpu core objects, which in turn construct CPU threads. For older machine versions it individually constructs the CPU threads. This division is going to make some future changes to the cpu construction harder, so this patch unifies them. Now cpu core objects are always created. This requires some updates to allow core objects to be created without a full complement of threads (since older versions allowed a number of cpus not a multiple of the threads-per-core). Likewise it needs some changes to the cpu core hot/cold plug path so as not to choke on the old machine types without hotplug support. For good measure, we move the cpu construction to its own subfunction, spapr_init_cpus(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>
* Move target-* CPU file into a target/ folderThomas Huth2016-12-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pseries: Split device tree construction from device tree loadDavid Gibson2016-10-281-1/+1
| | | | | | | | | | | | | | spapr_finalize_fdt() both finishes building the device tree for the guest and loads it into guest memory. For future cleanups, it's going to be more convenient to do these two things separately. The loading portion is pretty trivial, so we move it inline into the caller, ppc_spapr_reset(). We also rename spapr_finalize_fdt(), because the current name is going to become inaccurate. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
* numa: reduce code duplication by adding helper numa_get_node_for_cpu()Igor Mammedov2016-10-101-4/+2
| | | | | | | | | | | | | | | | | | Replace repeated pattern for (i = 0; i < nb_numa_nodes; i++) { if (test_bit(idx, numa_info[i].node_cpu)) { ... break; with a helper function to lookup numa node index for cpu. Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Shannon Zhao <shannon.zhao@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* spapr: fix check of cpu alias name in spapr_get_cpu_core_type()Greg Kurz2016-10-061-4/+4
| | | | | | | | | | | | | | | | | | If the user passes an alias name and a property to -cpu, QEMU fails to find the CPU definition and exits. $ qemu-system-ppc64 -cpu POWER8E,compat=power7 qemu-system-ppc64: Unable to find sPAPR CPU Core definition This happens because spapr_get_cpu_core_type() passes the full string from the command line (i.e. "POWER8E,compat=power7") to ppc_cpu_lookup_alias(), instead of the alias name piece only (i.e. "POWER8E"). The fix is to pass model_pieces[0] to ppc_cpu_lookup_alias(). Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Introduce sPAPRCPUCoreClassBharata B Rao2016-09-231-66/+38
| | | | | | | | | | | | | | | | | | | | | | Each spapr cpu core type defines an instance_init routine which just populates the CPU class name. This can be done in the class_init commonly for all core types which simplifies the registration. This is inspired by how PowerNV core types are registered. Certain types of spapr cpu cores ('host' and generic type based on host CPU) are initialized in target-ppc/kvm.c. To convert these type registrations to use class_init, we need to expose spapr_cpu_core_class_init() outside of spapr_cpu_core.c. Commit d11b268e1765 added a generic sPAPR CPU core family type to support cases like POWER8 CPU type on POWER8E host CPU. Switching to class_init would fix such scenarios to use the right CPU thread type instead of defaulting to host-powerpc64-cpu. In an unrelated cleanup, fix a typo in .get_hotplug_handler routine. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* hw/ppc/spapr: Look up CPU alias names instead of hard-coding the aliasesThomas Huth2016-08-101-17/+21
| | | | | | | | | | | | | | | | | | | | Hard-coding the CPU alias names in the spapr_cores[] array has two big disadvantages: 1) We register a real type with the CPU alias name in spapr_cpu_core_register_types() - this prevents us from registering a CPU family name in kvm_ppc_register_host_cpu_type() with the same name (as we do it for the non-hotpluggable CPU types). 2) It's quite cumbersome to maintain the aliases here in sync with the ppc_cpu_aliases list from target-ppc/cpu-models.c. So let's simply add proper alias lookup to the spapr cpu core code, too (by checking whether the given model can be used directly, and if not by trying to look up the given model as an alias name instead). Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* Merge remote-tracking branch 'remotes/armbru/tags/pull-error-2016-08-08' ↵Peter Maydell2016-08-081-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging Error reporting patches for 2016-08-08 # gpg: Signature made Mon 08 Aug 2016 08:14:49 BST # gpg: using RSA key 0x3870B400EB918653 # 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-error-2016-08-08: error: Fix error_printf() calls lacking newlines vfio: Use error_report() instead of error_printf() for errors checkpatch: Fix newline detection in error_setg() & friends error: Strip trailing '\n' from error string arguments (again) Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * error: Strip trailing '\n' from error string arguments (again)Markus Armbruster2016-08-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Commit 9af9e0f, 6daf194d, be62a2eb and 312fd5f got rid of a bunch, but they keep coming back. checkpatch.pl tries to flag them since commit 5d596c2, but it's not very good at it. Offenders tracked down with Coccinelle script scripts/coccinelle/err-bad-newline.cocci, an updated version of the script from commit 312fd5f. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1470224274-31522-2-git-send-email-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
* | spapr: Correctly set query_hotpluggable_cpus hook based on machine versionDavid Gibson2016-08-081-5/+2
|/ | | | | | | | | | | | | | | | | | | | | Prior to c8721d3 "spapr: Error out when CPU hotplug is attempted on older pseries machines", attempting to use query-hotpluggable-cpus on pseries-2.6 and earlier machine types would SEGV. That change fixed that, but due to some unexpected interactions in init order and a brown-paper-bag worthy failure to test, it accidentally disabled query-hotpluggable-cpus for all pseries machine types, including the current one which should allow it. In fact, query_hotpluggable_cpus needs to be non-NULL when and only when the dr_cpu_enabled flag in sPAPRMachineClass is set, which makes dr_cpu_enabled itself redundant. This patch removes dr_cpu_enabled, instead directly setting query_hotpluggable_cpus from the machine class_init functions, and using that to determine the availability of CPU hotplug when necessary. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Error out when CPU hotplug is attempted on older pseries machinesBharata B Rao2016-08-031-13/+6
| | | | | | | | | | | | | | | | | | | | | | CPU hotplug and coldplug aren't supported prior to pseries-2.7. Further, earlier machine types don't use CPU core objects at all. These mean that query-hotpluggable-cpus and coldplug on older pseries machines will crash QEMU. It also means that hotpluggable_cpus flag in query-machines will be incorrectly set to true for pseries < 2.7, since it is based on the presence of the query_hotpluggable_cpus hook. - Don't assign the query_hotpluggable_cpus hook for pseries < 2.7 - query_hotpluggable_cpus should therefore never be called on pseries < 2.7, so add an assert - spapr_core_pre_plug() should fail hot/cold plug attempts for pseries < 2.7, since core objects are never used there - spapr_core_plug() should therefore never be called for pseries < 2.7, so add an assert. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> [dwg: Change from query_hotpluggable_cpus returning NULL for pseries < 2.7 to not being called at all, reword commit message for accuracy] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Prevent boot CPU core removalBharata B Rao2016-07-291-0/+5
| | | | | | | | | | Boot CPU is assumed to be always present in QEMU code. So until that assumptions are gone, deny removal request. In another words, QEMU won't support boot CPU core hot-unplug. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> [dwg: Tweaked error message for clarity] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* Revert "spapr: Ensure CPU cores are added contiguously and removed in LIFO ↵David Gibson2016-07-291-19/+1
| | | | | | | | | | | | | | | | | order" This reverts commit 5cbc64de25973e9129c5a7897734a06ac64b9aff. Now that we have stable cpu_index values for pseries-2.7 (and future) machine types, we can now safely allow hotplug and unplug in any order. Conflicts: hw/ppc/spapr_cpu_core.c Some conflicts on revert due to some small changes in the inserted code since the original commit. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: init CPUState->cpu_index with index relative to core-idIgor Mammedov2016-07-291-0/+4
| | | | | | | | | | It will enshure that cpu_index for a given cpu stays the same regardless of the order cpus has been created/deleted and so it would be possible to migrate QEMU instance with out of order created CPU. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: disintricate core-id from DT semanticsGreg Kurz2016-07-251-13/+11
| | | | | | | | | | | | | | | | | | | | | | The goal of this patch is to have a stable core-id which does not depend on any DT related semantics, which involve non-obvious computations on modern PowerPC server cpus. With this patch, the DT core id is computed on-demand as: (core-id / smp_threads) * smt where smt is the number of threads per core in the host. This formula should be consolidated in a helper since it is needed in several places. Other uses for core-id includes: compute a stable cpu_index (which allows random order hotplug/unplug without breaking migration) and NUMA. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Ensure CPU cores are added contiguously and removed in LIFO orderBharata B Rao2016-07-181-1/+20
| | | | | | | | | | | | | | If CPU core addition or removal is allowed in random order leading to holes in the core id range (and hence in the cpu_index range), migration can fail as migration with holes in cpu_index range isn't yet handled correctly. Prevent this situation by enforcing the addition in contiguous order and removal in LIFO order so that we never end up with holes in cpu_index range. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: fix core unplug crashGreg Kurz2016-07-181-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | If the host has 8 threads/core and the guest is started with: -smp cores=1,threads=4,maxcpus=12 It is possible to crash QEMU by doing: (qemu) device_add host-spapr-cpu-core,core-id=16,id=foo (qemu) device_del foo Segmentation fault This happens because spapr_core_unplug() assumes cpu_dt_id == core_id. As long as cpu_dt_id is derived from the non-table cpu_index, this is only true when you plug cores with contiguous ids. It is safer to be consistent: the DR connector was created with an index that is immediately written to cc->core_id, and spapr_core_plug() also relies on cc->core_id. Let's use it also in spapr_core_unplug(). Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* Use #include "..." for our own headers, <...> for othersMarkus Armbruster2016-07-121-2/+2
| | | | | | | | | | | | Tracked down with an ugly, brittle and probably buggy Perl script. Also move includes converted to <...> up so they get included before ours where that's obviously okay. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Eric Blake <eblake@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
* spapr: Ensure thread0 of CPU core is always realized firstBharata B Rao2016-07-051-13/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | During CPU core realization, we create all the thread objects and parent them to the core object in a loop. However, the realization of thread objects is done separately by walking the threads of a core using object_child_foreach(). With this, there is no guarantee on the order in which the child thread objects get realized. Since CPU device tree properties are currently derived from the CPU thread object, we assume thread0 of the core to be the representative thread of the core when creating device tree properties for the core. If thread0 is not the first thread that gets realized, then we would end up having an incorrect dt_id for the core and this causes hotplug failures from the guest. Fix this by realizing each thread object by walking the core's thread object list thereby ensuring that thread0 and other threads are always realized in the correct order. Future TODO: CPU DT nodes are per-core properties and we should ideally base the creation of CPU DT nodes on core objects rather than the thread objects. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: drop duplicate variable in spapr_core_release()Greg Kurz2016-07-011-2/+1
| | | | | | Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: do proper error propagation in spapr_cpu_core_realize_child()Greg Kurz2016-07-011-5/+7
| | | | | | | | | This patch changes spapr_cpu_core_realize_child() to have a local error pointer and use error_propagate() as it is supposed to be done. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: drop reference on child object during core realizationGreg Kurz2016-07-011-0/+1
| | | | | | | | | | | | | | | | | | | | When a core is being realized, we create a child object for each thread of the core. The child is first initialized with object_initialize() which sets its ref count to 1, and then added to the core with object_property_add_child() which bumps the ref count to 2. When the core gets released, object_unparent() decreases the ref count to 1, and we g_free() the object: we hence loose the reference on an unfinalized object. This is likely to cause random crashes. Let's drop the extra reference as soon as we don't need it, after the thread is added to the core. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>