summaryrefslogtreecommitdiffstats
path: root/hw/ppc
Commit message (Collapse)AuthorAgeFilesLines
* spapr_drc: Change value of property "fdt" from null back to {}Markus Armbruster2015-12-041-0/+5
| | | | | | | | | | | | | | | prop_get_fdt() misuses the visitor API: when fdt is null, it doesn't visit anything. object_property_get_qobject() happily object_property_get_qobject(). Amazingly, the latter survives the misuse. Turns out we've papered over it long before prop_get_fdt() existed, in commit 1d10b44. However, commit 6c2f9a1 changed how we paper over it, and as a side effect changed qom-get's value from {} to null. Change it right back by fixing the visitor misuse. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr_drc: Make device "spapr-dr-connector" unavailable with -deviceMarkus Armbruster2015-12-041-0/+4
| | | | | | | | It should only be created via spapr_dr_connector_new(). Attempting to create it with -device crashes. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr_drc: Handle visitor errors properlyMarkus Armbruster2015-12-041-6/+26
| | | | | | | | Since prop_get_fdt() is only used with QmpOutputVisitor, errors shouldn't actually happen, so this is only a latent bug. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* hw/ppc/ppc405_boards: Fix infinite recursion by converting taihu_cpld from ↵Peter Maydell2015-11-301-44/+8
| | | | | | | | | | | | | | | | | | old_mmio The taihu_cpld_writel() function had an obvious typo that meant that if it was ever called it would go into an infinite recursion. Newer versions of clang will detect and warn about this: hw/ppc/ppc405_boards.c:481:1: warning: all paths through this function will call itself [-Winfinite-recursion] Fix this by converting taihu_cpld from the legacy old_mmio accessors to new-style ones, with an impl {} declaration to cause the core memory code to do the splitting of 16 bit and 32 bit accesses into multiple 8-bit accesses. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* hw/ppc/spapr: Remove duplicated "pseries" aliasThomas Huth2015-11-301-2/+0
| | | | | | | | | | | | The "pseries" alias is currently set twice, one time for the pseries-2.4 machine and one time for the "pseries-2.5" machine. To avoid confusion with the alias, let's remove the one from the older machine class. And while we're at it, also remove the "is_default = 0" there since the is_default variable should be set to zero by default already. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* Fix memory leak on errorStefano Dong (董兴水)2015-11-261-0/+1
| | | | | | | | | hw/ppc/spapr.c: Fix memory leak on error, it was introduced in bc09e0611 hw/acpi/memory_hotplug.c: Fix memory leak on error, it was introduced in 34f2af3d Signed-off-by: Stefano Dong (董兴水) <opensource.dxs@aliyun.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* ppc: Convert spapr code to use object property iteratorsDaniel P. Berrange2015-11-181-1/+4
| | | | | | | | | | | Stop directly accessing the Object::properties field data structure and instead use the formal object property iterator APIs. This insulates the code from future data structure changes in the Object struct. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Tested-by: Pavel Fedin <p.fedin@samsung.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
* cuda.c: add delay to setting of SR_INT bitMark Cave-Ayland2015-11-121-0/+3
| | | | | | | | | | MacOS 9 is racy when it comes to accessing the shift register. Fix this by introducing a small delay between data accesses and raising the SR_INT interrupt bit. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* PPC: mac99: Always add USB controllerAlexander Graf2015-11-121-1/+2
| | | | | | | | | | | | | The mac99 machines always have a USB controller. Usually not having one around doesn't hurt quite as much, but Mac OS 9 really really wants one or it crashes on bootup. So always add OHCI to make it happy. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Handle failure of KVM_PPC_ALLOCATE_HTAB ioctlBharata B Rao2015-11-111-4/+16
| | | | | | | | | | | | | | | | | KVM_PPC_ALLOCATE_HTAB ioctl can return -ENOMEM for KVM guests and QEMU never handled this correctly. But this didn't cause any problems till now as KVM_PPC_ALLOCATE_HTAB ioctl returned with smaller than requested HTAB when enough contiguous memory wasn't available in the host. After the proposed kernel change: https://patchwork.ozlabs.org/patch/530501/, KVM_PPC_ALLOCATE_HTAB ioctl will not fallback to lower sized HTAB allocation and will fail if requested HTAB size can't be met. Check for such failures in QEMU and abort appropriately. This will prevent guest kernel from hanging/freezing during early boot by doing graceful exit when host is unable to allocate requested HTAB. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* Rename save_live_complete to save_live_complete_precopyDr. David Alan Gilbert2015-11-101-1/+1
| | | | | | | | | | | In postcopy we're going to need to perform the complete phase for postcopiable devices at a different point, start out by renaming all of the 'complete's to make the difference obvious. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
* ppc/spapr: add 2.4 compat propsCornelia Huck2015-10-291-0/+9
| | | | | | | | HW_COMPAT_2_4 will become non-empty: prepare for it. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Message-id: 1444991154-79217-3-git-send-email-cornelia.huck@de.ibm.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* Revert "memhp: extend address auto assignment to support gaps"Michael S. Tsirkin2015-10-291-1/+1
| | | | | | | | This reverts commit df0acded19ec4b826aa095cfc19d341bd66fafd3. There's no point to it now that the only user has been reverted. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* prep: do not use CPU_LOG_IOPORT, convert to tracepointsPaolo Bonzini2015-10-231-27/+3
| | | | | | | | These messages are disabled by default; a perfect usecase for tracepoints. Convert them over. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/spapr: Add "ibm,pa-features" property to the device-treeBenjamin Herrenschmidt2015-10-231-0/+31
| | | | | | | | | | | | | | | | LoPAPR defines a "ibm,pa-features" per-CPU device tree property which describes extended features of the Processor Architecture. This adds the property to the device tree. At the moment this is the copy of what pHyp advertises except "I=1 (cache inhibited) Large Pages" which is enabled for TCG and disabled when running under HV KVM host with 4K system page size. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [aik: rebased, changed commit log, moved ci_large_pages initialization, renamed pa_features arrays] Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr_pci: Allow VFIO devices to work on the normal PCI host bridgeDavid Gibson2015-10-231-0/+6
| | | | | | | | | | | | | | | | | The core VFIO infrastructure more or less allows VFIO devices to work on any normal guest PCI host bridge (PHB) without extra logic. However, the "spapr-pci-host-bridge" device (as opposed to the special "spapr-pci-vfio-host-bridge" device) breaks this by using a partially KVM accelerated implementation of the guest kernel IOMMU which won't work with VFIO devices, without additional kernel support. This patch allows VFIO devices to work on the spapr-pci-host-bridge, by having it switch off KVM TCE acceleration when a VFIO device is added to the PHB (either on startup, or by hotplug). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
* spapr_iommu: Provide a function to switch a TCE table to allowing VFIODavid Gibson2015-10-231-0/+32
| | | | | | | | | | | | | | | | | Because of the way non-VFIO guest IOMMU operations are KVM accelerated, not all TCE tables (guest IOMMU contexts) can support VFIO devices. Currently, this is decided at creation time. To support hotplug of VFIO devices, we need to allow a TCE table which previously didn't allow VFIO devices to be switched so that it can. This patch adds an spapr_tce_set_need_vfio() function to do this, by reallocating the table in userspace if necessary. Currently this doesn't allow the KVM acceleration to be re-enabled if all the VFIO devices are removed. That's an optimization for another time. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
* spapr_iommu: Rename vfio_accel parameterDavid Gibson2015-10-231-3/+3
| | | | | | | | | | | | | | | | | | The vfio_accel parameter used when creating a new TCE table (guest IOMMU context) has a confusing name. What it really means is whether we need the TCE table created to be able to support VFIO devices. VFIO is relevant, because when available we use in-kernel acceleration of the TCE table, but that may not work with VFIO devices because updates to the table are handled in kernel, bypass qemu and so don't hit qemu's infrastructure for keeping the VFIO host IOMMU state in sync with the guest IOMMU state. Rename the parameter to "need_vfio" throughout. This is a cosmetic change, with no impact on the logic. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
* spapr_pci: Allow PCI host bridge DMA window to be configuredDavid Gibson2015-10-231-2/+5
| | | | | | | | | | | | | | | | | | At present the PCI host bridge (PHB) for the pseries machine type has a fixed DMA window from 0..1GB (in PCI address space) which is mapped to real memory via the PAPR paravirtualized IOMMU. For better support of VFIO devices, we're going to want to allow for different configurations of the DMA window. Eventually we'll want to allow the guest itself to reconfigure the window via the PAPR dynamic DMA window interface, but as a preliminary this patch allows the user to reconfigure the window with new properties on the PHB device. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
* spapr: Add "slb-size" property to CPU device tree nodesThomas Huth2015-10-231-0/+1
| | | | | | | | | | | | | | | According to a commit message in the Linux kernel (see here https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b60c31d85a2a for example), the name of the property that carries the information about the number of SLB entries should be called "slb-size", and not "ibm,slb-size". The Linux kernel can deal with both names, but to be on the safe side we should support the official name, too. [Now that LoPAPR is public, the relevant requirement can be found in section C.6.1.8 --dwg] Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Abort when HTAB of requested size isn't allocatedBharata B Rao2015-10-231-0/+8
| | | | | | | | | | | | | | Terminate the guest when HTAB of requested size isn't allocated by the host. When memory hotplug is attempted on a guest that has booted with less than requested HTAB size, the guest kernel will not be able to gracefully fail the hotplug request. This patch will ensure that we never end up in a situation where memory hotplug fails due to less than requested HTAB size. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Allocate HTAB from machine initBharata B Rao2015-10-231-7/+27
| | | | | | | | | | Allocate HTAB from ppc_spapr_init() so that we can abort the guest if requested HTAB size is't allocated by the host. However retain the htab reset call in spapr_reset_htab() so that HTAB gets reset (and not allocated) during machine reset. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/spapr: Allow VIRTIO_VGABenjamin Herrenschmidt2015-10-201-0/+1
| | | | | | | It works fine with the Linux driver out of the box Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* s/cpu_get_real_ticks/cpu_get_host_ticks/Christopher Covington2015-10-081-2/+2
| | | | | | | | | | | This should help clarify the purpose of the function that returns the host system's CPU cycle count. Signed-off-by: Christopher Covington <cov@codeaurora.org> Acked-by: Paolo Bonzini <pbonzini@redhat.com> ppc portion Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
* memhp: extend address auto assignment to support gapsIgor Mammedov2015-10-021-1/+1
| | | | | | | | | | setting gap to TRUE will make sparse DIMM address auto allocation, leaving gaps between a new DIMM address and preceeding existing DIMM. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* ppc: Rename ELF_MACHINE to be PPC specificPeter Crosthwaite2015-09-257-10/+10
| | | | | | | | | | | | | | | | Rename ELF_MACHINE to be PPC specific. This is used as-is by the various PPC bootloaders and is locally defined to ELF_MACHINE in linux user in PPC specific ifdeffery. This removes another architecture specific definition from the global namespace (as desired by multi-arch). Cc: Alexander Graf <agraf@suse.de> Cc: qemu-ppc@nongnu.org Reviewed-by: Richard Henderson <rth@twiddle.net> Acked-By: Riku Voipio <riku.voipio@linaro.org> Signed-off-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* sPAPR: Enable EEH on VFIO PCI device onlyGavin Shan2015-09-231-1/+1
| | | | | | | | | This checks if the PCI device retrieved from the PCI device address is VFIO PCI device when enabling EEH functionality. If it's not VFIO PCI device, the EEH functonality isn't enabled. Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* sPAPR: Revert don't enable EEH on emulated PCI devicesGavin Shan2015-09-231-7/+0
| | | | | | | | | | This reverts commit 7cb18007 ("sPAPR: Don't enable EEH on emulated PCI devices") as rtas_ibm_set_eeh_option() isn't the right place to check if there has the corresponding PCI device for the input address, which can be PE address, not PCI device address. Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/spapr: Implement H_RANDOM hypercall in QEMUThomas Huth2015-09-233-1/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PAPR interface defines a hypercall to pass high-quality hardware generated random numbers to guests. Recent kernels can already provide this hypercall to the guest if the right hardware random number generator is available. But in case the user wants to use another source like EGD, or QEMU is running with an older kernel, we should also have this call in QEMU, so that guests that do not support virtio-rng yet can get good random numbers, too. This patch now adds a new pseudo-device to QEMU that either directly provides this hypercall to the guest or is able to enable the in-kernel hypercall if available. The in-kernel hypercall can be enabled with the use-kvm property, e.g.: qemu-system-ppc64 -device spapr-rng,use-kvm=true For handling the hypercall in QEMU instead, a "RngBackend" is required since the hypercall should provide "good" random data instead of pseudo-random (like from a "simple" library function like rand() or g_random_int()). Since there are multiple RngBackends available, the user must select an appropriate back-end via the "rng" property of the device, e.g.: qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \ -device spapr-rng,rng=gid0 ... See http://wiki.qemu-project.org/Features-Done/VirtIORNG for other example of specifying RngBackends. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/spapr: Fix buffer overflow in spapr_populate_drconf_memory()Thomas Huth2015-09-231-3/+6
| | | | | | | | | | | | | | | | The buffer that is allocated in spapr_populate_drconf_memory() is used for setting both, the "ibm,dynamic-memory" and the "ibm,associativity-lookup-arrays" property. However, only the size of the first one is taken into account when allocating the memory. So if the length of the second property is larger than the length of the first one, we run into a buffer overflow here! Fix it by taking the length of the second property into account, too. Fixes: "spapr: Support ibm,dynamic-reconfiguration-memory" patch Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Fix default NUMA node allocation for threadsDavid Gibson2015-09-231-0/+8
| | | | | | | | | | | | | | | | | At present, if guest numa nodes are requested, but the cpus in each node are not specified, spapr just uses the default behaviour or assigning each vcpu round-robin to nodes. If smp_threads != 1, that will assign adjacent threads in a core to different NUMA nodes. As well as being just weird, that's a configuration that can't be represented in the device tree we give to the guest, which means the guest and qemu end up with different ideas of the NUMA topology. This patch implements mc->cpu_index_to_socket_id in the spapr code to make sure vcpus get assigned to nodes only at the socket granularity. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
* spapr: Move memory hotplug to RTAS_LOG_V6_HP_ID_DRC_COUNT typeBharata B Rao2015-09-231-1/+1
| | | | | | | | | | | | | | Till now memory hotplug used RTAS_LOG_V6_HP_ID_DRC_INDEX hotplug type which meant that we generated one hotplug type of EPOW event for every 256MB (SPAPR_MEMORY_BLOCK_SIZE). This quickly overruns the kernel rtas log buffer thus resulting in loss of memory hotplug events. Switch to RTAS_LOG_V6_HP_ID_DRC_COUNT hotplug type for memory so that we generate only one event per hotplug request. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Support hotplug by specifying DRC countBharata B Rao2015-09-233-12/+41
| | | | | | | | | | | | | | | | Support hotplug identifier type RTAS_LOG_V6_HP_ID_DRC_COUNT that allows hotplugging of DRCs by specifying the DRC count. While we are here, rename spapr_hotplug_req_add_event() to spapr_hotplug_req_add_by_index() spapr_hotplug_req_remove_event() to spapr_hotplug_req_remove_by_index() so that they match with spapr_hotplug_req_add_by_count(). Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Revert to memory@XXXX representation for non-hotplugged memoryBharata B Rao2015-09-231-38/+9
| | | | | | | | | | | | | | Don't represent non-hotluggable memory under drconf node. With this we don't have to create DRC objects for them. The effect of this patch is that we revert back to memory@XXXX representation for all the memory specified with -m option and represent the cold plugged memory and hot-pluggable memory under ibm,dynamic-reconfiguration-memory. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Populate ibm,associativity-lookup-arrays correctly for non-NUMABharata B Rao2015-09-231-2/+3
| | | | | | | | | | | | When NUMA isn't configured explicitly, assume node 0 is present for the purpose of creating ibm,associativity-lookup-arrays property under ibm,dynamic-reconfiguration-memory DT node. This ensures that the associativity index property is correctly updated in ibm,dynamic-memory for the LMB that is hotplugged. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Provide better error message when slots exceed max allowedBharata B Rao2015-09-231-2/+2
| | | | | | | | | | | | | | | Currently when user specifies more slots than allowed max of SPAPR_MAX_RAM_SLOTS (32), we error out like this: qemu-system-ppc64: unsupported amount of memory slots: 64 Let the user know about the max allowed slots like this: qemu-system-ppc64: Specified number of memory slots 64 exceeds max supported 32 Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Don't allow memory hotplug to memory less nodesBharata B Rao2015-09-231-1/+23
| | | | | | | | | | | | | | | | | | | Currently PowerPC kernel doesn't allow hot-adding memory to memory-less node, but instead will silently add the memory to the first node that has some memory. This causes two unexpected behaviours for the user. - Memory gets hotplugged to a different node than what the user specified. - Since pc-dimm subsystem in QEMU still thinks that memory belongs to memory-less node, a reboot will set things accordingly and the previously hotplugged memory now ends in the right node. This appears as if some memory moved from one node to another. So until kernel starts supporting memory hotplug to memory-less nodes, just prevent such attempts upfront in QEMU. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Memory hotplug supportBharata B Rao2015-09-232-3/+123
| | | | | | | | | Make use of pc-dimm infrastructure to support memory hotplug for PowerPC. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Make hash table size a factor of maxram_sizeBharata B Rao2015-09-231-1/+1
| | | | | | | | | | | | The hash table size is dependent on ram_size, but since with hotplug the memory can grow till maxram_size. Hence make hash table size dependent on maxram_size. This allows to hotplug huge amounts of memory to the guest. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Support ibm,dynamic-reconfiguration-memoryBharata B Rao2015-09-232-49/+212
| | | | | | | | | | | | | | | | | | | | Parse ibm,architecture.vec table obtained from the guest and enable memory node configuration via ibm,dynamic-reconfiguration-memory if guest supports it. This is in preparation to support memory hotplug for sPAPR guests. This changes the way memory node configuration is done. Currently all memory nodes are built upfront. But after this patch, only memory@0 node for RMA is built upfront. Guest kernel boots with just that and rest of the memory nodes (via memory@XXX or ibm,dynamic-reconfiguration-memory) are built when guest does ibm,client-architecture-support call. Note: This patch needs a SLOF enhancement which is already part of SLOF binary in QEMU. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Add LMB DR connectorsDavid Gibson2015-09-231-0/+87
| | | | | | | | | | | | | | | Enable memory hotplug for pseries 2.4 and add LMB DR connectors. With memory hotplug, enforce RAM size, NUMA node memory size and maxmem to be a multiple of SPAPR_MEMORY_BLOCK_SIZE (256M) since that's the granularity in which LMBs are represented and hot-added. LMB DR connectors will be used by the memory hotplug code. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> [spapr_drc_reset implementation] [since this missed the 2.4 cutoff, changing to only enable for 2.5] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Use QEMU limit for maximum CPUs numberAlexey Kardashevskiy2015-09-231-4/+2
| | | | | | | | | | | | | | | | | sPAPR uses hard coded limit of maximum 255 supported CPUs which is exactly the same as QEMU-wide limit which is MAX_CPUMASK_BITS and also defined as 255. This makes use of a global CPU number limit for the "pseries" machine. In order to anticipate future increase of the MAX_CPUMASK_BITS (or to help debugging large systems), this also bumps the FDT_MAX_SIZE limit from 256K to 1M assuming that 1 CPU core needs roughly 512 bytes in the device tree so the new limit can cover up to 2048 CPU cores. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Don't use QOM [*] syntax for DR connectors.David Gibson2015-09-231-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The dynamic reconfiguration (hotplug) code for the pseries machine type uses a "DR connector" QOM object for each resource it will be possible to hotplug. Each of these is added to its owner using object_property_add_child(owner, "dr-connector[*], ...); That works ok, mostly, but it means that the property indices are arbitrary, depending on the order in which the connectors are constructed. That might line up to something useful, but it doesn't have to. It will get worse once we add hotplug RAM support. That will add a DR connector object for every 256MB of potential memory. So if maxmem=2T, for example, there are 8192 objects under the same parent. The QOM interfaces aren't really designed for this. In particular object_property_add() with [*] has O(n^2) time complexity (in the number of existing children): first it has a linear search through array indices to find a free slot, each of which is attempted to a recursive call to object_property_add() with a specific [N]. Those calls are O(n) because there's a linear search through all properties to check for duplicates. By using a meaningful index value, which we already know is unique we can avoid the [*] special behaviour. That lets us reduce the total time for creating the DR objects from O(n^3) to O(n^2). O(n^2) is still kind of crappy, but it's enough to reduce the startup time of qemu (with in-progress memory hotplug support) with maxmem=2T from ~20 minutes to ~4 seconds. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Cc: Bharata B Rao <bharata@linux.vnet.ibm.com> Tested-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
* spapr_drc: use RTAS return codes for methods called by RTASMichael Roth2015-09-232-36/+41
| | | | | | | | | | | | | | | | | | | | | | | | | Certain methods in sPAPRDRConnector objects are only ever called by RTAS and in many cases are responsible for the logic that determines the RTAS return codes. Rather than having a level of indirection requiring RTAS code to re-interpret return values from such methods to determine the appropriate return code, just pass them through directly. This requires changing method return types to uint32_t to match the type of values currently passed to RTAS helpers. In the case of read accesses like drc->entity_sense() where we weren't previously reporting any errors, just the read value, we modify the function to return RTAS return code, and pass the read value back via reference. Suggested-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Suggested-by: David Gibson <david@gibson.dropbear.id.au> Cc: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Initialize hotplug memory address spaceBharata B Rao2015-09-231-0/+18
| | | | | | | | | | | | Initialize a hotplug memory region under which all the hotplugged memory is accommodated. Also enable memory hotplug by setting CONFIG_MEM_HOTPLUG. Modelled on i386 memory hotplug. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr_drc: don't allow 'empty' DRCs to be unisolated or allocatedMichael Roth2015-09-231-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Logical resources start with allocation-state:UNUSABLE / isolation-state:ISOLATED. During hotplug, guests will transition them to allocation-state:USABLE, and then to isolation-state:UNISOLATED. For cases where we cannot transition to allocation-state:USABLE, in this case due to no device/resource being association with the logical DRC, we should return an error -3. For physical DRCs, we default to allocation-state:USABLE and stay there, so in this case we should report an error -3 when the guest attempts to make the isolation-state:ISOLATED transition for a DRC with no device associated. These are as documented in PAPR 2.7, 13.5.3.4. We also ensure allocation-state:USABLE when the guest attempts transition to isolation-state:UNISOLATED to deal with misbehaving guests attempting to bring online an unallocated logical resource. This is as documented in PAPR 2.7, 13.7. Currently we implement no such error logic. Fix this by handling these error cases as PAPR defines. Cc: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr_pci: fix device tree props for MSI/MSI-XMichael Roth2015-09-231-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PAPR requires ibm,req#msi and ibm,req#msi-x to be present in the device node to define the number of msi/msi-x interrupts the device supports, respectively. Currently we have ibm,req#msi-x hardcoded to a non-sensical constant that happens to be 2, and are missing ibm,req#msi entirely. The result of that is that msi-x capable devices get limited to 2 msi-x interrupts (which can impact performance), and msi-only devices likely wouldn't work at all. Additionally, if devices expect a minimum that exceeds 2, the guest driver may fail to load entirely. SLOF still owns the generation of these properties at boot-time (although other device properties have since been offloaded to QEMU), but for hotplugged devices we rely on the values generated by QEMU and thus hit the limitations above. Fix this by generating these properties in QEMU as expected by guests. In the future it may make sense to modify SLOF to pass through these values directly as we do with other props since we're duplicating SLOF code. Cc: qemu-ppc@nongnu.org Cc: qemu-stable@nongnu.org Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Enable in-kernel H_SET_MODE handlingAlexey Kardashevskiy2015-09-231-0/+1
| | | | | | | | | | | | | | | | | For setting debug watchpoints, sPAPR guests use H_SET_MODE hypercall. The existing QEMU H_SET_MODE handler does not support this but the KVM handler in HV KVM does. However it is not enabled. This enables the in-kernel H_SET_MODE handler which handles: - Completed Instruction Address Breakpoint Register - Watch point 0 registers. The rest is still handled in QEMU. Reported-by: Anton Blanchard <anton@samba.org> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* pseries: Fix incorrect calculation of threads per socket for chip-idDavid Gibson2015-09-231-4/+2
| | | | | | | | | | | | | | | | | | | | | The device tree presented to pseries machine type guests includes an ibm,chip-id property which gives essentially the socket number of each vcpu core (individual vcpu threads don't get a node in the device tree). To calculate this, it uses a vcpus_per_socket variable computed as (smp_cpus / #sockets). This is correct for the usual case where smp_cpus == smp_threads * smp_cores * #sockets. However, you can start QEMU with the number of cores and threads mismatching the total number of vcpus (whether that _should_ be permitted is a topic for another day). It's a bit hard to say what the "real" number of vcpus per socket here is, but for most purposes (smp_threads * smp_cores) will more meaningfully match how QEMU behaves with respect to socket boundaries. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
* pseries: define coldplugged devices as "configured"Laurent Vivier2015-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | When a device is hotplugged, attach() sets "configured" to false, waiting an action from the OS to configure it and then to call ibm,configure-connector. On ibm,configure-connector, the hypervisor sets "configured" to true. In case of coldplugged device, attach() sets "configured" to false, but firmware and OS never call the ibm,configure-connector in this case, so it remains set to false. It could be harmless, but when we unplug a device, hypervisor waits the device becomes configured because for it, a not configured device is a device being configured, so it waits the end of configuration to unplug it... and it never happens, so it is never unplugged. This patch set by default coldplugged device to "configured=true", hotplugged device to "configured=false". Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
OpenPOWER on IntegriCloud