aboutsummaryrefslogtreecommitdiff
path: root/hw/ppc/spapr.c
AgeCommit message (Collapse)Author
2017-10-17ppc: spapr: use cpu model names as tcg defaults instead of aliasesIgor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-10-17ppc: spapr: use cpu type name directlyIgor Mammedov
replace sPAPRCPUCoreClass::cpu_class with cpu type name since it were needed just to get that at points it were accessed. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-10-17ppc: move '-cpu foo,compat=xxx' parsing into ppc_cpu_parse_featurestr()Igor Mammedov
there is a dedicated callback CPUClass::parse_features which purpose is to convert -cpu features into a set of global properties AND deal with compat/legacy features that couldn't be directly translated into CPU's properties. Create ppc variant of it (ppc_cpu_parse_featurestr) and move 'compat=val' handling from spapr_cpu_core.c into it. That removes a dependency of board/core code on cpu_model parsing and would let to reuse common -cpu parsing introduced by 6063d4c0 Set "max-cpu-compat" property only if it exists, in practice it should limit 'compat' hack to spapr machine and allow to avoid including machine/spapr headers in target/ppc/cpu.c Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-10-17hw/ppc/spapr.c: abort unplug_request if previous unplug isn't doneDaniel Henrique Barboza
LMB removal is completed only when the spapr_lmb_release callback is called after all DRCs of the dimm are detached. During this time, it is possible that a unplug request for the same dimm arrives, trying to detach DRCs that were detached by the guest in the first unplug_request. BQL doesn't help in this case - the lock will prevent any concurrent removal from happening until the end of spapr_memory_unplug_request only. What happens is that the second unplug_request ends up calling spapr_drc_detach in a DRC that were detached already, causing an assert error in spapr_drc_detach (e.g https://bugs.launchpad.net/qemu/+bug/1718118). spapr_lmb_release uses a structure called sPAPRDIMMState, stored in the spapr->pending_dimm_unplugs QTAIL, to track how many LMB DRCs are left to be detached by the guest. When there are no more DRCs left, this structure is deleted and the pc-dimm unplug handler is called to finish the process. This patch reuses the sPAPRDIMMState to allow unplug_request to know if there is an ongoing unplug process for a given dimm, aborting the unplug request in this case, by doing the following changes: - in spapr_lmb_release callback, move the dimm state removal to the end, after pc-dimm unplug handler. With this change we can check for the existence of the dimm state to see if the unplug process is done. - use spapr_pending_dimm_unplugs_find in spapr_memory_unplug_request to check if the dimm state exists. If positive, there is an unplug operation already in progress for this dimm, meaning that we should abort it and warn the user about it. Fixes: https://bugs.launchpad.net/qemu/+bug/1718118 Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-10-17spapr: sanity check size of the CAS bufferGreg Kurz
The CAS buffer is provided by SLOF. A broken SLOF could pass a silly size: either smaller than the diff header, in which case the current code will try to allocate 16 Exabytes of memory and g_malloc0() will abort, or bigger than the maximum memory provisioned for SLOF (ie, 40 Megabytes), which doesn't make sense. Both cases indicate that SLOF has a bug. Let's print out an explicit error message and exit since rebooting as we do with other errors would only result in a reset loop. Signed-off-by: Greg Kurz <groug@kaod.org> [dwg: Fix format specifier that broke 32-bit builds] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-10-17spapr: fix OF word name in commentGreg Kurz
Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-10-17hw/ppc: use 0 instead of fdt_path_offset(fdt, "/")Greg Kurz
The offset of the root node is guaranteed to be 0. This doesn't fix anything, it's just trivial cleanup of the two remaining places where this was done under hw/ppc. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-27spapr: fix the value of SDR1 in kvmppc_put_books_sregs()Greg Kurz
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>
2017-09-27spapr: introduce helpers to migrate HPT chunks and the end markerGreg Kurz
This consolidates some duplicated code in a dedicated helpers. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-27ppc/kvm: generalize the use of kvmppc_get_htab_fd()Greg Kurz
The use of KVM_PPC_GET_HTAB_FD is open-coded in kvmppc_read_hptes() and kvmppc_write_hpte(). This patch modifies kvmppc_get_htab_fd() so that it can be used everywhere we need to access the in-kernel htab: - add an index argument => only kvmppc_read_hptes() passes an actual index, all other users pass 0 - add an errp argument to propagate error messages to the caller. => spapr migration code prints the error => hpte helpers pass &error_abort to keep the current behavior of hw_error() While here, this also fixes a bug in kvmppc_write_hpte() so that it opens the htab fd for writing instead of reading as it currently does. This never broke anything because we currently never call this code, as explained in the changelog of commit c1385933804bb: "This support updating htab managed by the hypervisor. Currently we don't have any user for this feature. This actually bring the store_hpte interface in-line with the load_hpte one. We may want to use this when we want to emulate henter hcall in qemu for HV kvm." The above is still true today. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-27ppc/kvm: change kvmppc_get_htab_fd() to return -errno on errorGreg Kurz
When kvmppc_get_htab_fd() fails, its return value is propagated up to qemu_savevm_state_iterate() or to qemu_savevm_state_complete_precopy(). All savevm handlers expect to receive a negative errno on error. Let's patch kvmppc_get_htab_fd() accordingly. While here, let's change htab_load() in the spapr code to also propagate the error, since it doesn't make sense to abort() if we couldn't get the htab fd from KVM. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-19numa: cpu: calculate/set default node-ids after all -numa CLI options are parsedIgor Mammedov
Calculating default node-ids for CPUs in possible_cpu_arch_ids() is rather fragile since defaults calculation uses nb_numa_nodes but callback might be potentially called early before all -numa CLI options are parsed, which would lead to cpus assigned only upto nb_numa_nodes at the time possible_cpu_arch_ids() is called. Issue was introduced by (7c88e65 numa: mirror cpu to node mapping in MachineState::possible_cpus) and for example CLI: -smp 4 -numa node,cpus=0 -numa node would set props.node-id in possible_cpus array for every non explicitly mapped CPU to the first node. Issue is not visible to guest nor to mgmt interface due to 1) implictly mapped cpus are forced to the first node in case of partial mapping 2) in case of default mapping possible_cpu_arch_ids() is called after all -numa options are parsed (resulting in correct mapping). However it's fragile to rely on late execution of possible_cpu_arch_ids(), therefore add machine specific callback that returns node-id for CPU and use it to calculate/ set defaults at machine_numa_finish_init() time when all -numa options are parsed. Reported-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1496314408-163972-1-git-send-email-imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-09-15ppc/xive: fix OV5_XIVE_EXPLOIT bitsCédric Le Goater
On POWER9, the Client Architecture Support (CAS) negotiation process determines whether the guest operates in XIVE Legacy compatibility or in XIVE exploitation mode. Now that we have initial guest support for the XIVE interrupt controller, let's fix the bits definition which have evolved in the latest specs. The platform advertises the XIVE Exploitation Mode support using the property "ibm,arch-vec-5-platform-support-vec-5", byte 23 bits 0-1 : - 0b00 XIVE legacy mode Only - 0b01 XIVE exploitation mode Only - 0b10 XIVE legacy or exploitation mode The OS asks for XIVE Exploitation Mode support using the property "ibm,architecture-vec-5", byte 23 bits 0-1: - 0b00 XIVE legacy mode Only - 0b01 XIVE exploitation mode Only Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-15hw/ppc/spapr.c: cleaning up qdev_get_machine() callsDaniel Henrique Barboza
This patch removes the qdev_get_machine() calls that are made in spapr.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. The following changes were made: - spapr_node0_size: static function that is called two times: at spapr_setup_hpt_and_vrma and ppc_spapr_init. In both cases we can pass an existing MachineState pointer to it. - spapr_build_fdt: MachineState pointer can be retrieved from the existing sPAPRMachineState pointer. - spapr_boot_set: the opaque in the first arg is a sPAPRMachineState pointer as we can see inside ppc_spapr_init: qemu_register_boot_set(spapr_boot_set, spapr); We can get a MachineState pointer from it. - spapr_machine_device_plug and spapr_machine_device_unplug_request: the MachineState, sPAPRMachineState, MachineClass and sPAPRMachineClass pointers can all be retrieved from the HotplugHandler pointer. Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-08PPC: KVM: Support machine option to set VSMT modeSam Bobroff
KVM now allows writing to KVM_CAP_PPC_SMT which has previously been read only. Doing so causes KVM to act, for that VM, as if the host's SMT mode was the given value. This is particularly important on Power 9 systems because their default value is 1, but they are able to support values up to 8. This patch introduces a way to control this capability via a new machine property called VSMT ("Virtual SMT"). If the value is not set on the command line a default is chosen that is, when possible, compatible with legacy systems. Note that the intialization of KVM_CAP_PPC_SMT has changed slightly because it has changed (in KVM) from a global capability to a VM-specific one. This won't cause a problem on older KVMs because VM capabilities fall back to global ones. Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-08ppc: spapr: Make VCPU ID handling private to SPAPRSam Bobroff
The concept of a VCPU ID that differs from the CPU's index (cpu->cpu_index) exists only within SPAPR machines so, move the functions ppc_get_vcpu_id() and ppc_get_cpu_by_vcpu_id() into spapr.c and rename them appropriately. Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-08ppc: spapr: Rename cpu_dt_id to vcpu_idSam Bobroff
This field actually records the VCPU ID used by KVM and, although the value is also used in the device tree it is primarily the VCPU ID so rename it as such. Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com> [dwg: Updated comment missed in cpu.h] Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-08spapr: add pseries-2.11 machine typeGreg Kurz
Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-08hw/ppc: CAS reset on early device hotplugDaniel Henrique Barboza
This patch is a follow up on the discussions made in patch "hw/ppc: disable hotplug before CAS is completed" that can be found at [1]. At this moment, we do not support CPU/memory hotplug in early boot stages, before CAS. When a hotplug occurs, the event is logged in an internal RTAS event log queue and an IRQ pulse is fired. In regular conditions, the guest handles the interrupt by executing check_exception, fetching the generated hotplug event and enabling the device for use. In early boot, this IRQ isn't caught (SLOF does not handle hotplug events), leaving the event in the rtas event log queue. If the guest executes check_exception due to another hotplug event, the re-assertion of the IRQ ends up de-queuing the first hotplug event as well. In short, a device hotplugged before CAS is considered coldplugged by SLOF. This leads to device misbehavior and, in some cases, guest kernel Ooops when trying to unplug the device. A proper fix would be to turn every device hotplugged before CAS as a colplugged device. This is not trivial to do with the current code base though - the FDT is written in the guest memory at ppc_spapr_reset and can't be retrieved without adding extra state (fdt_size for example) that will need to managed and migrated. Adding the hotplugged DT in the middle of CAS negotiation via the updated DT tree works with CPU devs, but panics the guest kernel at boot. Additional analysis would be necessary for LMBs and PCI devices. There are questions to be made in QEMU/SLOF/kernel level about how we can make this change in a sustainable way. With Linux guests, a fix would be the kernel executing check_exception at boot time, de-queueing the events that happened in early boot and processing them. However, even if/when the newer kernels start fetching these events at boot time, we need to take care of older kernels that won't be doing that. This patch works around the situation by issuing a CAS reset if a hotplugged device is detected during CAS: - the DRC conditions that warrant a CAS reset is the same as those that triggers a DRC migration - the DRC must have a device attached and the DRC state is not equal to its ready_state. With that in mind, this patch makes use of 'spapr_drc_needed' to determine if a CAS reset is needed. - In the middle of CAS negotiations, the function 'spapr_hotplugged_dev_before_cas' goes through all the DRCs to see if there are any DRC that requires a reset, using spapr_drc_needed. If that happens, returns '1' in 'spapr_h_cas_compose_response' which will set spapr->cas_reboot to true, causing the machine to reboot. No changes are made for coldplug devices. [1] http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02855.html Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-08hw/ppc: clear pending_events on machine resetDaniel Henrique Barboza
The sPAPR machine isn't clearing up the pending events QTAILQ on machine reboot. This allows for unprocessed hotplug/epow events to persist in the queue after reset and, when reasserting the IRQs in check_exception later on, these will be being processed by the OS. This patch implements a new function called 'spapr_clear_pending_events' that clears up the pending_events QTAILQ. This helper is then called inside ppc_spapr_reset to clear up the events queue, preventing old/deprecated events from persisting after a reset. Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-08-22hw/ppc/spapr: Fix segfault when instantiating a 'pc-dimm' without 'memdev'Thomas Huth
QEMU currently crashes when trying to use a 'pc-dimm' on the pseries machine without specifying its 'memdev' property. This happens because pc_dimm_get_memory_region() does not check whether the 'memdev' property has properly been set by the user. Looking closer at this function, it's also obvious that it is using &error_abort to call another function - and this is bad in a function that is used in the hot-plugging calling chain since this can also cause QEMU to exit unexpectedly. So let's fix these issues in a proper way now: Add a "Error **errp" parameter to pc_dimm_get_memory_region() which we use in case the 'memdev' property has not been set by the user, and which we can use instead of the &error_abort, and change the callers of get_memory_region() to make use of this "errp" parameter for proper error checking. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-29Revert "spapr: populate device tree depending on XIVE_EXPLOIT option"David Gibson
This reverts commit b87680427e8a3ff682f66514e99a8344e7437247. I thought this was a harmless preliminary for XIVE enablement patches we expect later on. However, due to some subtle interactions between qemu and SLOF (guest firmware) this breaks some things. Revert it for now, we'll work out how to fix it when the rest of the XIVE patches are ready. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-25spapr: Fix QEMU abort during memory unplugBharata B Rao
Commit 0cffce56 (hw/ppc/spapr.c: adding pending_dimm_unplugs to sPAPRMachineState) introduced a new way to track pending LMBs of DIMM device that is marked for removal. Since this commit we can hit the assert in spapr_pending_dimm_unplugs_add() in the following situation: - DIMM device removal fails as the guest doesn't allow the removal. - Subsequent attempt to remove the same DIMM would hit the assert as the corresponding sPAPRDIMMState is still part of the pending_dimm_unplugs list. Fix this by removing the assert and conditionally adding the sPAPRDIMMState to pending_dimm_unplugs list only when it is not already present. Fixes: 0cffce56ae3501c5783d779f97993ce478acf856 Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> [dwg: Tweaked to avoid returning NULL when spapr_pending_dimm_unplugs_add() does find an existing entry] Reviewed-by: Daniel Barboza <danielhb@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-25spapr/htab: fix savevmLaurent Vivier
Commit 3a38429 ("spapr: Add a "no HPT" encoding to HTAB migration stream") allows to migrate an empty HPT, but doesn't mark correctly the end of the migration stream. The end condition (value returned by htab_save_iterate()) should be 1, whereas in 3a38429 it returns 0. The problem can be reproduced with QEMU monitor command "savevm": the command never stops and the disk image grows without limit. Fixes: 3a38429748aa4f74abaecf16c4c087e8a325e12a Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-17spapr: fix memory leak in spapr_core_pre_plug()Greg Kurz
In case of error, we must ensure the dynamically allocated base_core_type is freed, like it is done everywhere else in this function. This is a regression introduced in QEMU 2.9 by commit 8149e2992f78. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-17pseries: Use smaller default hash page tables when guest can resizeDavid Gibson
We've now implemented a PAPR extension allowing PAPR guest to resize their hash page table (HPT) during runtime. This patch makes use of that facility to allocate smaller HPTs by default. Specifically when a guest is aware of the HPT resize facility, qemu sizes the HPT to the initial memory size, rather than the maximum memory size on the assumption that the guest will resize its HPT if necessary for hot plugged memory. When the initial memory size is much smaller than the maximum memory size (a common configuration with e.g. oVirt / RHEV) then this can save significant memory on the HPT. If the guest does *not* advertise HPT resize awareness when it makes the ibm,client-architecture-support call, qemu resizes the HPT for maxmimum memory size (unless it's been configured not to allow such guests at all). For now we make that reallocation assuming the guest has not yet used the HPT at all. That's true in practice, but not, strictly, an architectural or PAPR requirement. If we need to in future we can fix this by having the client-architecture-support call reboot the guest with the revised HPT size (the client-architecture-support call is explicitly permitted to trigger a reboot in this way). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
2017-07-17pseries: Enable HPT resizing for 2.10David Gibson
We've now implemented a PAPR extensions which allows PAPR guests (i.e. "pseries" machine type) to resize their hash page table during runtime. However, that extension is only enabled if explicitly chosen on the command line. This patch enables it by default for spapr-2.10, but leaves it disabled (by default) for older machine types. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
2017-07-17pseries: Implement HPT resizingDavid Gibson
This patch implements hypercalls allowing a PAPR guest to resize its own hash page table. This will eventually allow for more flexible memory hotplug. The implementation is partially asynchronous, handled in a special thread running the hpt_prepare_thread() function. The state of a pending resize is stored in SPAPR_MACHINE->pending_hpt. The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or, if one is already in progress, monitor it for completion. If there is an existing HPT resize in progress that doesn't match the size specified in the call, it will cancel it, replacing it with a new one matching the given size. The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only be called successfully once H_RESIZE_HPT_PREPARE has successfully completed initialization of a new HPT. The guest must ensure that there are no concurrent accesses to the existing HPT while this is called (this effectively means stop_machine() for Linux guests). For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each HPTE into the new HPT. This can have quite high latency, but it seems to be of the order of typical migration downtime latencies for HPTs of size up to ~2GiB (which would be used in a 256GiB guest). In future we probably want to move more of the rehashing to the "prepare" phase, by having H_ENTER and other hcalls update both current and pending HPTs. That's a project for another day, but should be possible without any changes to the guest interface. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-17pseries: Stubs for HPT resizingDavid Gibson
This introduces stub implementations of the H_RESIZE_HPT_PREPARE and H_RESIZE_HPT_COMMIT hypercalls which we hope to add in a PAPR extension to allow run time resizing of a guest's hash page table. It also adds a new machine property for controlling whether this new facility is available. For now we only allow resizing with TCG, allowing it with KVM will require kernel changes as well. Finally, it adds a new string to the hypertas property in the device tree, advertising to the guest the availability of the HPT resizing hypercalls. This is a tentative suggested value, and would need to be standardized by PAPR before being merged. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
2017-07-17spapr: fix potential memory leak in spapr_core_plug()Greg Kurz
Since commit 5c1da81215c7 ("spapr: Remove unnecessary differences between hotplug and coldplug paths"), the CPU DT for the DRC is always allocated. This causes a memory leak for pseries-2.6 and older machine types, that don't support CPU hotplug and don't allocate DRCs for CPUs. Reported-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-17spapr: Refactor spapr_drc_detach()David Gibson
This function has two unused parameters - remove them. It also sets awaiting_release on all paths, except one. On that path setting it is harmless, since it will be immediately cleared by spapr_drc_release(). So factor it out of the if statements. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Daniel Barboza <danielhb@linux.vnet.ibm.com>
2017-07-17spapr: Simplify unplug pathDavid Gibson
spapr_lmb_release() and spapr_core_release() call hotplug_handler_unplug() which after a bunch of indirection calls spapr_memory_unplug() or spapr_core_unplug(). But we already know which is the appropriate thing to call here, so we can just fold it directly into the release function. Once that's done, there's no need for an hc->unplug method in the spapr machine at all: since we also have an hc->unplug_request method, the hotplug core will never use ->unplug. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Daniel Barboza <danielhb@linux.vnet.ibm.com>
2017-07-17spapr: Treat devices added before inbound migration as coldpluggedLaurent Vivier
When migrating a guest which has already had devices hotplugged, libvirt typically starts the destination qemu with -incoming defer, adds those hotplugged devices with qmp, then initiates the incoming migration. This causes problems for the management of spapr DRC state. Because the device is treated as hotplugged, it goes into a DRC state for a device immediately after it's plugged, but before the guest has acknowledged its presence. However, chances are the guest on the source machine *has* acknowledged the device's presence and configured it. If the source has fully configured the device, then DRC state won't be sent in the migration stream: for maximum migration compatibility with earlier versions we don't migrate DRCs in coldplug-equivalent state. That means that the DRC effectively changes state over the migrate, causing problems later on. In addition, logging hotplug events for these devices isn't what we want because a) those events should already have been issued on the source host and b) the event queue should get wiped out by the incoming state anyway. In short, what we really want is to treat devices added before an incoming migration as if they were coldplugged. To do this, we first add a spapr_drc_hotplugged() helper which determines if the device is hotplugged in the sense relevant for DRC state management. We only send hotplug events when this is true. Second, when we add a device which isn't hotplugged in this sense, we force a reset of the DRC state - this ensures the DRC is in a coldplug-equivalent state (there isn't usually a system reset between these device adds and the incoming migration). This is based on an earlier patch by Laurent Vivier, cleaned up and extended. Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Daniel Barboza <danielhb@linux.vnet.ibm.com>
2017-07-17spapr: Minor cleanups to events handlingDavid Gibson
The rtas_error_log structure is marked packed, which strongly suggests its precise layout is important to match an external interface. Along with that one could expect it to have a fixed endianness to match the same interface. That used to be the case - matching the layout of PAPR RTAS event format and requiring BE fields. Now, however, it's only used embedded within sPAPREventLogEntry with the fields in native order, since they're processed internally. Clear that up by removing the nested structure in sPAPREventLogEntry. struct rtas_error_log is moved back to spapr_events.c where it is used as a temporary to help convert the fields in sPAPREventLogEntry to the correct in memory format when delivering an event to the guest. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-17spapr: migrate pending_events of spapr stateDaniel Henrique Barboza
In racing situations between hotplug events and migration operation, a rtas hotplug event could have not yet be delivered to the source guest when migration is started. In this case the pending_events of spapr state need be transmitted to the target so that the hotplug event can be finished on the target. To achieve the minimal VMSD possible to migrate the pending_events list, this patch makes the changes in spapr_events.c: - 'log_type' of sPAPREventLogEntry struct deleted. This information can be derived by inspecting the rtas_error_log summary field. A new function called 'spapr_event_log_entry_type' was added to retrieve the type of a given sPAPREventLogEntry. - sPAPREventLogEntry, epow_log_full and hp_log_full were redesigned. The only data we're going to migrate in the VMSD is the event log data itself, which can be divided in two parts: a rtas_error_log header and an extended event log field. The rtas_error_log header contains information about the size of the extended log field, which can be used inside VMSD as the size parameter of the VBUFFER_ALOC field that will store it. To allow this use, the header.extended_length field must be exposed inline to the VMSD instead of embedded into a 'data' field that holds everything. With this in mind, the following changes were done: * a new 'header' field was added to sPAPREventLogEntry. This field holds a a struct rtas_error_log inline. * the declaration of the 'rtas_error_log' struct was moved to spapr.h to be visible to the VMSD macros. * 'data' field of sPAPREventLogEntry was renamed to 'extended_log' and now holds only the contents of the extended event log. * 'struct rtas_error_log hdr' were taken away from both epow_log_full and hp_log_full. This information is now available at the header field of sPAPREventLogEntry. * epow_log_full and hp_log_full were renamed to epow_extended_log and hp_extended_log respectively. This rename makes it clearer to understand the new purpose of both structures: hold the information of an extended event log field. * spapr_powerdown_req and spapr_hotplug_req_event now creates a sPAPREventLogEntry structure that contains the full rtas log entry. * rtas_event_log_queue and rtas_event_log_dequeue now receives a sPAPREventLogEntry pointer as a parameter instead of a void pointer. - the endianess of the sPAPREventLogEntry header is now native instead of be32. We can use the fields in native endianess internally and write them in be32 in the guest physical memory inside 'check_exception'. This allows the VMSD inside spapr.c to read the correct size of the entended_log field. - inside spapr.c, pending_events is put in a subsection in the spapr state VMSD to make sure migration across different versions is not broken. A small change in rtas_event_log_queue and rtas_event_log_dequeue were also made: instead of calling qdev_get_machine(), both functions now receive a pointer to the sPAPRMachineState. This pointer is already available in the callers of these functions and we don't need to waste resources calling qdev() again. Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-13Convert error_report() to warn_report()Alistair Francis
Convert all uses of error_report("warning:"... to use warn_report() instead. This helps standardise on a single method of printing warnings to the user. All of the warnings were changed using these two commands: find ./* -type f -exec sed -i \ 's|error_report(".*warning[,:] |warn_report("|Ig' {} + Indentation fixed up manually afterwards. The test-qdev-global-props test case was manually updated to ensure that this patch passes make check (as the test cases are case sensitive). Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Suggested-by: Thomas Huth <thuth@redhat.com> Cc: Jeff Cody <jcody@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Lieven <pl@kamp.de> Cc: Josh Durgin <jdurgin@redhat.com> Cc: "Richard W.M. Jones" <rjones@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Peter Crosthwaite <crosthwaite.peter@gmail.com> Cc: Richard Henderson <rth@twiddle.net> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> Cc: Greg Kurz <groug@kaod.org> Cc: Rob Herring <robh@kernel.org> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Peter Chubb <peter.chubb@nicta.com.au> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Alexander Graf <agraf@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Greg Kurz <groug@kaod.org> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed by: Peter Chubb <peter.chubb@data61.csiro.au> Acked-by: Max Reitz <mreitz@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Message-Id: <e1cfa2cd47087c248dd24caca9c33d9af0c499b0.1499866456.git.alistair.francis@xilinx.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-07-11Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.10-20170711' ↵Peter Maydell
into staging ppc patch queue 2017-07-11 * Several minor cleanups from Greg Kurz * Fix for migration of pseries-2.7 and earlier machine types * More reworking of the DRC hotplug code, fixing several problems though there are still more to go * Fixes for CPU family / alias handling on POWER9 * Preliminary patches for POWER9 XIVE (new interrupt controller) support * Assorted other fixes # gpg: Signature made Tue 11 Jul 2017 05:35:16 BST # gpg: using RSA key 0x6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.10-20170711: spapr: populate device tree depending on XIVE_EXPLOIT option spapr: introduce the XIVE_EXPLOIT option in CAS ppc/kvm: have the "family" CPU alias to point to TYPE_HOST_POWERPC_CPU spapr: Only report host/guest IOMMU page size mismatches on KVM spapr: fix memory hotplug error path target/ppc: Add debug function for radix mmu translation target/ppc: Refactor tcg radix mmu code spapr: Use unplug_request for PCI hot unplug spapr: Remove unnecessary differences between hotplug and coldplug paths spapr: Add DRC release method spapr: Uniform DRC reset paths spapr: Leave DR-indicator management to the guest target-ppc: SPR_BOOKE_ESR not set on FP exceptions spapr: fix migration to pseries machine < 2.8 spapr: fix bogus function name in comment spapr: refresh "platform-specific" hcalls comment spapr: make spapr_populate_hotplug_cpu_dt() static Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-07-11spapr: populate device tree depending on XIVE_EXPLOIT optionCédric Le Goater
When XIVE is supported, the device tree should be populated accordingly and the XIVE memory regions mapped to activate MMIOs. Depending on the design we choose, we could also allocate different ICS and ICP objects, or switch between objects. This needs to be discussed. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-11spapr: introduce the XIVE_EXPLOIT option in CASCédric Le Goater
On POWER9, the Client Architecture Support (CAS) negotiation process determines whether the guest operates in XIVE Legacy compatibility (the former POWER8 interrupt model) or in XIVE exploitation mode (the newer POWER9 interrupt model). Bit 7 of Byte 23 of vector 5 is used for this purpose. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-11spapr: fix memory hotplug error pathGreg Kurz
QEMU shouldn't abort if spapr_add_lmbs()->spapr_drc_attach() fails. Let's propagate the error instead, like it is done everywhere else where spapr_drc_attach() is called. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Daniel Barboza <danielhb@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-11spapr: Remove unnecessary differences between hotplug and coldplug pathsDavid Gibson
spapr_drc_attach() has a 'coldplug' parameter which sets the DRC into configured state initially, instead of the usual ISOLATED/UNUSABLE state. It turns out this is unnecessary: although coldplugged devices do need to be in CONFIGURED state once the guest starts, that will already be accomplished by the reset code which will move DRCs for already plugged devices into a coldplug equivalent state. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
2017-07-11spapr: Uniform DRC reset pathsDavid Gibson
DRC objects have a regular device reset method. However, it only gets called in the usual way for PCI DRCs. Because of where CPU and LMB DRCs are in the QOM tree, their device reset method isn't automatically called. So, the machine manually registers reset handlers to call device_reset(). This patch removes the device reset method, and instead always explicitly registers the reset handler from realize(). This means the callers don't have to worry about the two cases, and we always get proper resets. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
2017-07-11spapr: fix bogus function name in commentGreg Kurz
$ git grep spapr_ppc_reset hw/ppc/spapr.c: * as part of spapr_ppc_reset(). $ git grep ppc_spapr_reset hw/ppc/spapr.c:static void ppc_spapr_reset(void) hw/ppc/spapr.c: mc->reset = ppc_spapr_reset; hw/ppc/spapr_hcall.c: /* If ppc_spapr_reset() did not set up a HPT but one is necessary Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-11spapr: make spapr_populate_hotplug_cpu_dt() staticGreg Kurz
Since commit ff9006ddbfd1 ("spapr: move spapr_core_[foo]plug() callbacks close to machine code in spapr.c"), this function doesn't need to be extern anymore. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-07-10migration: Rename cleanup() to save_cleanup()Juan Quintela
We need a cleanup for loads, so we rename here to be consistent. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> -- Rename htab_cleanup to htap_save_cleanup as dave suggestion Message-Id: <20170628095228.4661-3-quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-07-10migration: Rename save_live_setup() to save_setup()Juan Quintela
We are going to use it now for more than save live regions. Once there rename qemu_savevm_state_begin() to qemu_savevm_state_setup(). Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20170628095228.4661-2-quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-06-30spapr: Make DRC reset force DRC into known stateDavid Gibson
The reset handler for DRCs attempts several state transitions which are subject to various checks and restrictions. But at reset time we know there is no guest, so we can ignore most of the usual sequencing rules and just set the DRC back to a known state. In fact, it's safer to do so. The existing code also has several redundant checks for drc->awaiting_release inside a block which has already tested that. This patch removes those and sets the DRC to a fixed initial state based only on whether a device is currently plugged or not. With DRCs correctly reset to a state based on device presence, we don't need to force state transitions as cold plugged devices are processed. This allows us to remove all the callers of the set_*_state() methods from outside spapr_drc.c. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-06-30hw/ppc/spapr.c: consecutive 'spapr->patb_entry = 0' statementsDaniel Henrique Barboza
In ppc_spapr_reset(), if the guest is using HPT, the code was executing: } else { spapr->patb_entry = 0; spapr_setup_hpt_and_vrma(spapr); } And, at the end of spapr_setup_hpt_and_vrma: /* We're setting up a hash table, so that means we're not radix */ spapr->patb_entry = 0; Resulting in spapr->patb_entry being assigned to 0 twice in a row. Given that 'spapr_setup_hpt_and_vrma' is also called inside 'spapr_check_setup_free_hpt' of spapr_hcall.c, this trivial patch removes the 'patb_entry = 0' assignment from the 'else' clause inside ppc_spapr_reset to avoid this behavior. Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-06-30spapr: fix migration of ICPState objects from/to older QEMUGreg Kurz
Commit 5bc8d26de20c ("spapr: allocate the ICPState object from under sPAPRCPUCore") moved ICPState objects from the machine to CPU cores. This is an improvement since we no longer allocate ICPState objects that will never be used. But it has the side-effect of breaking migration of older machine types from older QEMU versions. This patch allows spapr to register dummy "icp/server" entries to vmstate. These entries use a dedicated VMStateDescription that can swallow and discard state of an incoming migration stream, and that don't send anything on outgoing migration. As for real ICPState objects, the instance_id is the cpu_index of the corresponding vCPU, which happens to be equal to the generated instance_id of older machine types. The machine can unregister/register these entries when CPUs are dynamically plugged/unplugged. This is only available for pseries-2.9 and older machines, thanks to a compat property. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-06-30spapr: Fix migration of Radix guestsBharata B Rao
Fix migration of radix guests by ensuring that we issue KVM_PPC_CONFIGURE_V3_MMU for radix case post migration. Reported-by: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com> Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>