aboutsummaryrefslogtreecommitdiff
path: root/hw/ppc
AgeCommit message (Collapse)AuthorFilesLines
2015-09-25ppc: Rename ELF_MACHINE to be PPC specificPeter Crosthwaite7-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>
2015-09-23sPAPR: Enable EEH on VFIO PCI device onlyGavin Shan1-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>
2015-09-23sPAPR: Revert don't enable EEH on emulated PCI devicesGavin Shan1-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>
2015-09-23ppc/spapr: Implement H_RANDOM hypercall in QEMUThomas Huth3-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>
2015-09-23ppc/spapr: Fix buffer overflow in spapr_populate_drconf_memory()Thomas Huth1-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>
2015-09-23spapr: Fix default NUMA node allocation for threadsDavid Gibson1-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>
2015-09-23spapr: Move memory hotplug to RTAS_LOG_V6_HP_ID_DRC_COUNT typeBharata B Rao1-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>
2015-09-23spapr: Support hotplug by specifying DRC countBharata B Rao3-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>
2015-09-23spapr: Revert to memory@XXXX representation for non-hotplugged memoryBharata B Rao1-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>
2015-09-23spapr: Populate ibm,associativity-lookup-arrays correctly for non-NUMABharata B Rao1-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>
2015-09-23spapr: Provide better error message when slots exceed max allowedBharata B Rao1-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>
2015-09-23spapr: Don't allow memory hotplug to memory less nodesBharata B Rao1-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>
2015-09-23spapr: Memory hotplug supportBharata B Rao2-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>
2015-09-23spapr: Make hash table size a factor of maxram_sizeBharata B Rao1-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>
2015-09-23spapr: Support ibm,dynamic-reconfiguration-memoryBharata B Rao2-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>
2015-09-23spapr: Add LMB DR connectorsDavid Gibson1-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>
2015-09-23spapr: Use QEMU limit for maximum CPUs numberAlexey Kardashevskiy1-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>
2015-09-23spapr: Don't use QOM [*] syntax for DR connectors.David Gibson1-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>
2015-09-23spapr_drc: use RTAS return codes for methods called by RTASMichael Roth2-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>
2015-09-23spapr: Initialize hotplug memory address spaceBharata B Rao1-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>
2015-09-23spapr_drc: don't allow 'empty' DRCs to be unisolated or allocatedMichael Roth1-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>
2015-09-23spapr_pci: fix device tree props for MSI/MSI-XMichael Roth1-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>
2015-09-23spapr: Enable in-kernel H_SET_MODE handlingAlexey Kardashevskiy1-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>
2015-09-23pseries: Fix incorrect calculation of threads per socket for chip-idDavid Gibson1-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>
2015-09-23pseries: define coldplugged devices as "configured"Laurent Vivier1-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>
2015-09-23sPAPR: Introduce rtas_ldq()Gavin Shan1-10/+10
This introduces rtas_ldq() to load 64-bits parameter from continuous two 4-bytes memory chunk of RTAS parameter buffer, to simplify the code. Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Reviewed-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>
2015-09-23spapr_rtas: Prevent QEMU crash during hotplug without a prior device_addBharata B Rao1-0/+6
If drmgr is used in the guest to hotplug a device before a device_add has been issued via the QEMU monitor, QEMU segfaults in configure_connector call. This occurs due to accessing of NULL FDT which otherwise would have been created and associated with the DRC during device_add command. Check for NULL FDT and return failure from configure_connector call. As per PAPR+, an error value of -9003 seems appropriate for this failure. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Cc: 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>
2015-09-23ppc/spapr: Use qemu_log_mask() for hcall_dprintf()Thomas Huth1-1/+2
To see the output of the hcall_dprintf statements, you currently have to enable the DEBUG_SPAPR_HCALLS macro in include/hw/ppc/spapr.h. This is ugly because a) not every user who wants to debug guest problems can or wants to recompile QEMU to be able to see such issues, and b) since this macro is disabled by default, the code in the hcall_dprintf() brackets tends to bitrot until somebody temporarily enables that macro again. Since the hcall_dprintf statements except one indicate guest problems, let's always use qemu_log_mask(LOG_GUEST_ERROR, ...) for this macro instead. One spot indicated an unimplemented host feature, so this is changed into qemu_log_mask(LOG_UNIMP, ...) instead. Now it's possible to see all those messages by simply adding the CLI parameter "-d guest_errors,unimp", without the need to re-compile the binary. 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>
2015-09-23spapr_drc: Fix potential undefined behaviourDavid Gibson1-1/+1
The DRC_INDEX_ID_MASK macro does a left shift on ~0, which is a signed quantity, and therefore undefined behaviour according to the C spec. In particular this causes warnings from the clang sanitizer. This fixes it by calculating the same mask without using ~0 (I think the new method is a more common idiom for generating masks anyway). For good measure I also use 1ULL to force the expression's type to unsigned long long, which should be good for assigning to anything we're going to want to. Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2015-09-23spapr: add dumpdtb supportAndrew Jones1-0/+2
dumpdtb (-machine dumpdtb=<file>) allows one to inspect the generated device tree of machine types that generate device trees. This is useful for a) seeing what's there b) debugging/testing device tree generator patches. It can be used as follows $QEMU_CMDLINE -machine dumpdtb=dtb dtc -I dtb -O dts dtb Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-23spapr: SPLPAR CharacteristicsSam Bobroff1-2/+9
Improve the SPLPAR Characteristics information: Add MaxPlatProcs: set to max_cpus, the maximum CPUs that could be addded to the system. Add DesMem: set to the initial memory of the system. Add DesProcs: set to smp_cpus, the inital number of CPUs in the system. These tokens and values are specified by PAPR. Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-23spapr: Make ibm, change-msi respect 3 return valuesSam Bobroff1-1/+3
Currently, rtas_ibm_change_msi() always returns four values even if less are specified. Correct this by only returning the fourth parameter if it was requested. This is specified by PAPR. Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-23spapr: Add /rtas/ibm,change-msix-capableSam Bobroff1-0/+4
QEMU is MSI-X capable and makes it available via ibm,change-msi, so we should indicate this by adding /rtas/ibm,change-msix-capable to the device tree. This is specificed by PAPR. Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-23spapr: Add /ibm,partition-nameSam Bobroff1-0/+5
QEMU has a notion of the guest name, so if it's present we might as well put that into the device tree as /ibm,partition-name. This is specificed by PAPR. Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-23spapr: Create pseries-2.5 machineDavid Gibson1-1/+18
Add pseries-2.5 machine version. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> [Altered to merge before memory hotplug -- dwg] [Altered to work with b9f072d01 -- dwg] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-23spapr: Provide an error message when migration fails due to htab_shift mismatchBharata B Rao1-0/+2
Include an error message when migration fails due to mismatch in htab_shift values at source and target. This should provide a bit more verbose message in addition to the current migration failure message that reads like: qemu-system-ppc64: error while loading state for instance 0x0 of device 'spapr/htab' After this patch, the failure message will look like this: qemu-system-ppc64: htab_shift mismatch: source 29 target 24 qemu-system-ppc64: error while loading state for instance 0x0 of device 'spapr/htab' Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-20kvm_ppc: remove kvmppc_timer_hackPaolo Bonzini2-7/+0
QEMU does have an I/O thread now, that can be interrupted at any time because the VCPU thread runs outside the iothread mutex. Therefore, the kvmppc_timer_hack is obsolete. Remove it. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2015-09-19Revert use of DEFINE_MACHINE() for registrations of multiple machinesAndreas Färber1-4/+24
The script used for converting from QEMUMachine had used one DEFINE_MACHINE() per machine registered. In cases where multiple machines are registered from one source file, avoid the excessive generation of module init functions by reverting this unrolling. Signed-off-by: Andreas Färber <afaerber@suse.de>
2015-09-19Use DEFINE_MACHINE() to register all machinesEduardo Habkost7-79/+45
Convert all machines to use DEFINE_MACHINE() instead of QEMUMachine automatically using a script. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> [AF: Style cleanups, convert imx25_pdk machine] Signed-off-by: Andreas Färber <afaerber@suse.de>
2015-09-19mac_world: Break long lineEduardo Habkost1-1/+2
Coding style change only. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
2015-09-19machine: Set MachineClass::name automaticallyEduardo Habkost2-5/+0
Now all TYPE_MACHINE subclasses use MACHINE_TYPE_NAME to generate the class name. So instead of requiring each subclass to set MachineClass::name manually, we can now set it automatically at the TYPE_MACHINE class_base_init() function. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> [AF/ehabkost: Updated for s390-ccw machines] [AF: Cleanup of intermediate virt and vexpress name handling] Signed-off-by: Andreas Färber <afaerber@suse.de>
2015-09-19mac99: Use MACHINE_TYPE_NAME to encode class nameEduardo Habkost1-1/+1
It will result in exactly the same class name, but it will make the code consistent with the other classes. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Andreas Färber <afaerber@suse.de>
2015-09-19pseries: Rename machine class names to use MACHINE_TYPE_NAMEEduardo Habkost1-4/+4
Machine class names should use the "-machine" suffix to allow class-name-based machine class lookup to work. Rename the the pseries machine classes using the MACHINE_TYPE_NAME macro. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Andreas Färber <afaerber@suse.de>
2015-09-18Fix bad error handling after memory_region_init_ram()Markus Armbruster4-6/+7
Symptom: $ qemu-system-x86_64 -m 10000000 Unexpected error in ram_block_add() at /work/armbru/qemu/exec.c:1456: upstream-qemu: cannot set up guest memory 'pc.ram': Cannot allocate memory Aborted (core dumped) Root cause: commit ef701d7 screwed up handling of out-of-memory conditions. Before the commit, we report the error and exit(1), in one place, ram_block_add(). The commit lifts the error handling up the call chain some, to three places. Fine. Except it uses &error_abort in these places, changing the behavior from exit(1) to abort(), and thus undoing the work of commit 3922825 "exec: Don't abort when we can't allocate guest memory". The three places are: * memory_region_init_ram() Commit 4994653 (right after commit ef701d7) lifted the error handling further, through memory_region_init_ram(), multiplying the incorrect use of &error_abort. Later on, imitation of existing (bad) code may have created more. * memory_region_init_ram_ptr() The &error_abort is still there. * memory_region_init_rom_device() Doesn't need fixing, because commit 33e0eb5 (soon after commit ef701d7) lifted the error handling further, and in the process changed it from &error_abort to passing it up the call chain. Correct, because the callers are realize() methods. Fix the error handling after memory_region_init_ram() with a Coccinelle semantic patch: @r@ expression mr, owner, name, size, err; position p; @@ memory_region_init_ram(mr, owner, name, size, ( - &error_abort + &error_fatal | err@p ) ); @script:python@ p << r.p; @@ print "%s:%s:%s" % (p[0].file, p[0].line, p[0].column) When the last argument is &error_abort, it gets replaced by &error_fatal. This is the fix. If the last argument is anything else, its position is reported. This lets us check the fix is complete. Four positions get reported: * ram_backend_memory_alloc() Error is passed up the call chain, ultimately through user_creatable_complete(). As far as I can tell, it's callers all handle the error sanely. * fsl_imx25_realize(), fsl_imx31_realize(), dp8393x_realize() DeviceClass.realize() methods, errors handled sanely further up the call chain. We're good. Test case again behaves: $ qemu-system-x86_64 -m 10000000 qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory [Exit 1 ] The next commits will repair the rest of commit ef701d7's damage. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1441983105-26376-3-git-send-email-armbru@redhat.com> Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com>
2015-09-14Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell2-12/+1
* Support for jemalloc * qemu_mutex_lock_iothread "No such process" fix * cutils: qemu_strto* wrappers * iohandler.c simplification * Many other fixes and misc patches. And some MTTCG work (with Emilio's fixes squashed): * Signal-free TCG kick * Removing spinlock in favor of QemuMutex * User-mode emulation multi-threading fixes/docs # gpg: Signature made Thu 10 Sep 2015 09:03:07 BST using RSA key ID 78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" * remotes/bonzini/tags/for-upstream: (44 commits) cutils: work around platform differences in strto{l,ul,ll,ull} cpu-exec: fix lock hierarchy for user-mode emulation exec: make mmap_lock/mmap_unlock globally available tcg: comment on which functions have to be called with mmap_lock held tcg: add memory barriers in page_find_alloc accesses remove unused spinlock. replace spinlock by QemuMutex. cpus: remove tcg_halt_cond and tcg_cpu_thread globals cpus: protect work list with work_mutex scripts/dump-guest-memory.py: fix after RAMBlock change configure: Add support for jemalloc add macro file for coccinelle configure: factor out adding disas configure vhost-scsi: fix wrong vhost-scsi firmware path checkpatch: remove tests that are not relevant outside the kernel checkpatch: adapt some tests to QEMU CODING_STYLE: update mixed declaration rules qmp: Add example usage of strto*l() qemu wrapper cutils: Add qemu_strtoull() wrapper cutils: Add qemu_strtoll() wrapper ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-09-11maint: avoid useless "if (foo) free(foo)" patternMarkus Armbruster1-8/+4
My Coccinelle semantic patch finds a few more, because it also fixes up the equally pointless conditional if (foo) { free(foo); foo = NULL; } Result (feel free to squash it into your patch): Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2015-09-09use qemu_cpu_kick instead of cpu_exit or qemu_cpu_kick_threadPaolo Bonzini1-1/+1
Use the same API to trigger interruption of a CPU, no matter if under TCG or KVM. There is no difference: these calls come from the CPU thread, so the qemu_cpu_kick calls will send a signal to the running thread and it will be processed synchronously, just like a call to cpu_exit. The only difference is in the overhead, but neither call to cpu_exit (now qemu_cpu_kick) is in a hot path. Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-09-09i8257: remove cpu_request_exit irqPaolo Bonzini1-11/+0
This is unused. cpu_exit now is almost exclusively an internal function to the CPU execution loop. In a few patches, we'll change the remaining occurrences to qemu_cpu_kick, making it truly internal. Reviewed-by: Richard henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-08-13pci: allow 0 address for PCI IO/MEM regionsLaurent Vivier1-0/+1
Some kernels program a 0 address for io regions. PCI 3.0 spec section 6.2.5.1 doesn't seem to disallow this. based on patch by Michael Roth <mdroth@linux.vnet.ibm.com> Add pci_allow_0_addr in MachineClass to conditionally allow addr 0 for pseries, as this can break other architectures. This patch allows to hotplug PCI card in pseries machine, as the first added card BAR0 is always set to 0 address. This as a temporary hack, waiting to fix PCI memory priorities for more machine types... Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-07-20timer: rename NSEC_PER_SEC due to Mac OS X header clashStefan Hajnoczi2-6/+7
Commit e0cf11f31c24cfb17f44ed46c254d84c78e7f6e9 ("timer: Use a single definition of NSEC_PER_SEC for the whole codebase") renamed NANOSECONDS_PER_SECOND to NSEC_PER_SEC. On Mac OS X there is a <dispatch/time.h> system header which also defines NSEC_PER_SEC. This causes compiler warnings. Let's use the old name instead. It's longer but it doesn't clash. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 1436364609-7929-1-git-send-email-stefanha@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
generated by cgit v1.1 at 2024-12-26 04:36:08 +0000