aboutsummaryrefslogtreecommitdiff
path: root/hw/ppc
AgeCommit message (Collapse)AuthorFilesLines
2017-02-25Merge remote-tracking branch 'remotes/stsquad/tags/pull-mttcg-240217-1' into ↵Peter Maydell2-1/+18
staging This is the MTTCG pull-request as posted yesterday. # gpg: Signature made Fri 24 Feb 2017 11:17:51 GMT # gpg: using RSA key 0xFBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * remotes/stsquad/tags/pull-mttcg-240217-1: (24 commits) tcg: enable MTTCG by default for ARM on x86 hosts hw/misc/imx6_src: defer clearing of SRC_SCR reset bits target-arm: ensure all cross vCPUs TLB flushes complete target-arm: don't generate WFE/YIELD calls for MTTCG target-arm/powerctl: defer cpu reset work to CPU context cputlb: introduce tlb_flush_*_all_cpus[_synced] cputlb: atomically update tlb fields used by tlb_reset_dirty cputlb: add tlb_flush_by_mmuidx async routines cputlb and arm/sparc targets: convert mmuidx flushes from varg to bitmap cputlb: introduce tlb_flush_* async work. cputlb: tweak qemu_ram_addr_from_host_nofail reporting cputlb: add assert_cpu_is_self checks tcg: handle EXCP_ATOMIC exception for system emulation tcg: enable thread-per-vCPU tcg: enable tb_lock() for SoftMMU tcg: remove global exit_request tcg: drop global lock during TCG code execution tcg: rename tcg_current_cpu to tcg_current_rr_cpu tcg: add kick timer for single-threaded vCPU emulation tcg: add options for enabling MTTCG ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-02-24tcg: drop global lock during TCG code executionJan Kiszka2-1/+18
This finally allows TCG to benefit from the iothread introduction: Drop the global mutex while running pure TCG CPU code. Reacquire the lock when entering MMIO or PIO emulation, or when leaving the TCG loop. We have to revert a few optimization for the current TCG threading model, namely kicking the TCG thread in qemu_mutex_lock_iothread and not kicking it in qemu_cpu_kick. We also need to disable RAM block reordering until we have a more efficient locking mechanism at hand. Still, a Linux x86 UP guest and my Musicpal ARM model boot fine here. These numbers demonstrate where we gain something: 20338 jan 20 0 331m 75m 6904 R 99 0.9 0:50.95 qemu-system-arm 20337 jan 20 0 331m 75m 6904 S 20 0.9 0:26.50 qemu-system-arm The guest CPU was fully loaded, but the iothread could still run mostly independent on a second core. Without the patch we don't get beyond 32206 jan 20 0 330m 73m 7036 R 82 0.9 1:06.00 qemu-system-arm 32204 jan 20 0 330m 73m 7036 S 21 0.9 0:17.03 qemu-system-arm We don't benefit significantly, though, when the guest is not fully loading a host CPU. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Message-Id: <1439220437-23957-10-git-send-email-fred.konrad@greensocs.com> [FK: Rebase, fix qemu_devices_reset deadlock, rm address_space_* mutex] Signed-off-by: KONRAD Frederic <fred.konrad@greensocs.com> [EGC: fixed iothread lock for cpu-exec IRQ handling] Signed-off-by: Emilio G. Cota <cota@braap.org> [AJB: -smp single-threaded fix, clean commit msg, BQL fixes] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Reviewed-by: Pranith Kumar <bobby.prani@gmail.com> [PM: target-arm changes] Acked-by: Peter Maydell <peter.maydell@linaro.org>
2017-02-22hw/ppc/ppc405_uc.c: Avoid integer overflowsPeter Maydell1-3/+3
When performing clock calculations, the ppc405_uc code has several places where it multiplies together two 32-bit variables and assigns the result to a 64-bit variable. This doesn't quite do what is intended because C will compute a 32-bit multiply result. Add casts to ensure we don't truncate the result. (Spotted by Coverity, CID 1005504, 1005505.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22hw/ppc/spapr: Check for valid page size when hot plugging memoryThomas Huth1-0/+8
On POWER, the valid page sizes that the guest can use are bound to the CPU and not to the memory region. QEMU already has some fancy logic to find out the right maximum memory size to tell it to the guest during boot (see getrampagesize() in the file target/ppc/kvm.c for more information). However, once we're booted and the guest is using huge pages already, it is currently still possible to hot-plug memory regions that does not support huge pages - which of course does not work on POWER, since the guest thinks that it is possible to use huge pages everywhere. The KVM_RUN ioctl will then abort with -EFAULT, QEMU spills out a not very helpful error message together with a register dump and the user is annoyed that the VM unexpectedly died. To avoid this situation, we should check the page size of hot-plugged DIMMs to see whether it is possible to use it in the current VM. If it does not fit, we can print out a better error message and refuse to add it, so that the VM does not die unexpectely and the user has a second chance to plug a DIMM with a matching memory backend instead. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1419466 Signed-off-by: Thomas Huth <thuth@redhat.com> [dwg: Fix a build error on 32-bit builds with KVM] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22machine: replace query_hotpluggable_cpus() callback with ↵Igor Mammedov1-10/+10
has_hotpluggable_cpus flag Generic helper machine_query_hotpluggable_cpus() replaced target specific query_hotpluggable_cpus() callbacks so there is no need in it anymore. However inon NULL callback value is used to detect/report hotpluggable cpus support, therefore it can be removed completely. Replace it with MachineClass.has_hotpluggable_cpus boolean which is sufficient for the task. Suggested-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22machine: unify [pc_|spapr_]query_hotpluggable_cpus() callbacksIgor Mammedov1-32/+2
All callbacks FOO_query_hotpluggable_cpus() are practically the same except of setting vcpus_count to different values. Convert them to a generic machine_query_hotpluggable_cpus() callback by moving vcpus_count initialization to per machine specific callback possible_cpu_arch_ids(). Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22spapr: reuse machine->possible_cpus instead of cores[]Igor Mammedov1-39/+90
Replace SPAPR specific cores[] array with generic machine->possible_cpus and store core objects there. It makes cores bookkeeping similar to x86 cpus and will allow to unify similar code. It would allow to replace cpu_index based NUMA node mapping with iproperty based one (for -device created cores) since possible_cpus carries board defined topology/layout. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22spapr: replace debug printf with trace pointsLaurent Vivier2-14/+7
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22ppc4xx: replace debug printf with trace pointsLaurent Vivier2-10/+7
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22mac99: replace debug printf with trace pointsLaurent Vivier2-12/+7
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22spapr: fix off-by-one error in spapr_ovec_populate_dt()Sam Bobroff1-1/+1
The last byte of the option vector was missing due to an off-by-one error. Without this fix, client architecture support negotiation will fail because the last byte of option vector 5, which contains the MMU support, will be missed. Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22hw/ppc/pnv: Remove superfluous "qemu" prefix from error stringsThomas Huth1-3/+3
error_report() already puts a prefix with the program name in front of the error strings, so the "qemu:" prefix is not necessary here anymore. Reported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22spapr: make cpu core unplug follow expected hotunplug call flowIgor Mammedov1-4/+14
spapr_core_unplug() were essentially spapr_core_unplug_request() handler that requested CPU removal and registered callback which did actual cpu core removali but it was called from spapr_machine_device_unplug() which is intended for actual object removal. Commit (cf632463 spapr: Memory hot-unplug support) sort of fixed it introducing spapr_machine_device_unplug_request() and calling spapr_core_unplug() but it hasn't renamed callback and by mistake calls it from spapr_machine_device_unplug(). However spapr_machine_device_unplug() isn't ever called for cpu core since spapr_core_release() doesn't follow expected hotunplug call flow which is: 1: device_del() -> hotplug_handler_unplug_request() -> set destroy_cb() 2: destroy_cb() -> hotplug_handler_unplug() -> object_unparent // actual device removal Fix it by renaming spapr_core_unplug() to spapr_core_unplug_request() which is called from spapr_machine_device_unplug_request() and making spapr_core_release() call hotplug_handler_unplug() which will call spapr_machine_device_unplug() -> spapr_core_unplug() to remove cpu core. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reveiwed-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22spapr: move spapr_core_[foo]plug() callbacks close to machine code in spapr.cIgor Mammedov2-138/+138
spapr_core_pre_plug/spapr_core_plug/spapr_core_unplug() are managing wiring CPU core into spapr machine state and not internal CPU core state. So move them from spapr_cpu_core.c to spapr.c where other similar (spapr_memory_[foo]plug()) callbacks are located, which also matches x86 target practice. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-22spapr: cpu core: separate child threads destruction from machine state ↵Igor Mammedov1-5/+10
operations Split off destroying VCPU threads from drc callback spapr_core_release() into new spapr_cpu_core_unrealizefn() which takes care of internal cpu core state cleanup (i.e. VCPU threads) and is called when object_unparent(core) is called. That leaves spapr_core_release() only with board mgmt code, which will be moved to board related file in follow up patch along with the rest on hotplug callbacks. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-21hw: Default -drive to if=ide explicitly where it worksMarkus Armbruster3-0/+3
Block backends defined with -drive if=ide are meant to be picked up by machine initialization code: a suitable frontend gets created and wired up automatically. if=ide drives not picked up that way can still be used with -device as if they had if=none, but that's unclean and best avoided. Unused ones produce an "Orphaned drive without device" warning. -drive parameter "if" is optional, and the default depends on the machine type. If a machine type doesn't specify a default, the default is "ide". Many machine types default to if=ide, even though they don't actually have an IDE controller. A future patch will change these defaults to something more sensible. To prepare for it, this patch makes default "ide" explicit for the machines that actually pick up if=ide drives: * alpha: clipper * arm/aarch64: spitz borzoi terrier tosa * i386/x86_64: generic-pc-machine (with concrete subtypes pc-q35-* pc-i440fx-* pc-* isapc xenfv) * mips64el: fulong2e * mips/mipsel/mips64el: malta mips * ppc/ppc64: mac99 g3beige prep * sh4/sh4eb: r2d * sparc64: sun4u sun4v Note that ppc64 machine powernv already sets an "ide" default explicitly. Its IDE controller isn't implemented, yet. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <1487153147-11530-2-git-send-email-armbru@redhat.com>
2017-02-16report guest crash information in GUEST_PANICKED eventAnton Nefedov1-1/+2
it's not very convenient to use the crash-information property interface, so provide a CPU class callback to get the guest crash information, and pass that information in the event Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> Message-Id: <1487053524-18674-3-git-send-email-den@openvz.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-02-02hw/ppc/pnv: Use error_report instead of hw_error if a ROM file can't be foundThomas Huth1-3/+3
hw_error() is for CPU related errors only (it dumps the CPU registers and calls abort()!), so using error_report() is the better choice of reporting an error in case we simply did not find a file. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-02-02target-ppc: Add MMU model check for booke machinesValentin Plotkin3-0/+19
Machines bamboo, e500 and virtex-ml507 assume a certain MMU model, otherwise resulting in unpredictable behavior. Add apropriate checks into *_init functions. Signed-off-by: Valentin Plotkin <caliborn@sdf.org> [regarding virtex parts] Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31ppc: switch to constants within BUILD_BUG_ONMichael S. Tsirkin1-8/+10
We are switching BUILD_BUG_ON to verify that it's parameter is a compile-time constant, and it turns out that some gcc versions (specifically gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609) are not smart enough to figure it out for expressions involving local variables. This is harmless but means that the check is ineffective for these platforms. To fix, replace the variable with macros. Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> [dwg: Correct a printf format warning] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31spapr: clock should count only if vm is runningLaurent Vivier2-23/+49
This is a port to ppc of the i386 commit: 00f4d64 kvmclock: clock should count only if vm is running We remove timebase_post_load function, and use the VM state change handler to save and restore the guest_timebase (on stop and continue). We keep timebase_pre_save to reduce the clock difference on migration like in: 6053a86 kvmclock: reduce kvmclock difference on migration Time base offset has originally been introduced by commit 98a8b52 spapr: Add support for time base offset migration So while VM is paused, the time is stopped. This allows to have the same result with date (based on Time Base Register) and hwclock (based on "get-time-of-day" RTAS call). Moreover in TCG mode, the Time Base is always paused, so this patch also adjust the behavior between TCG and KVM. VM state field "time_of_the_day_ns" is now useless but we keep it to be able to migrate to older version of the machine. As vmstate_ppc_timebase structure (with timebase_pre_save() and timebase_post_load() functions) was only used by vmstate_spapr, we register the VM state change handler only in ppc_spapr_init(). Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31ppc: Remove unused function cpu_ppc601_rtc_init()Thomas Huth1-7/+0
It is completely unused, thus it can be removed without problems. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31ppc: Prevent inifnite loop in decrementer auto-reload.Roman Kapl1-2/+6
If the DECAR register is set to 0, QEMU tries to reload the decrementer with zero in an inifinite loop. According to PPC documentation, the decrementer is triggered on 1->0 transition, so avoid reloading the decrementer if if is already zero. The problem does not manifest under Linux, but it is valid to set DECAR to zero (and may make sense as part of decrementer initialization when interrupts are disabled). Signed-off-by: Roman Kapl <rka@sysgo.com> [dwg: Fixed style nit] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31ppc: Add ppc_set_compat_all()David Gibson1-26/+5
Once a compatiblity mode is negotiated with the guest, h_client_architecture_support() uses run_on_cpu() to update each CPU to the new mode. We're going to want this logic somewhere else shortly, so make a helper function to do this global update. We put it in target-ppc/compat.c - it makes as much sense at the CPU level as it does at the machine level. We also move the cpu_synchronize_state() into ppc_set_compat(), since it doesn't really make any sense to call that without synchronizing state. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31pseries: Rewrite CAS PVR compatibility logicDavid Gibson2-72/+34
During boot, PAPR guests negotiate CPU model support with the ibm,client-architecture-support mechanism. The logic to implement this in qemu is very convoluted. This cleans it up to be cleaner, using the new ppc_check_compat() call. The new logic for choosing a compatibility mode is: 1. Usually, use the most recent compatibility mode that is a) supported by the guest b) supported by the CPU and c) no later than the maximum allowed (if specified) 2. If no suitable compatibility mode was found, the guest *does* support this CPU explicitly, and no maximum compatibility mode is specified, then use "raw" mode for the current CPU 3. Otherwise, fail the boot. This differs from the results of the old code: the old code preferred using "raw" mode to a compatibility mode, whereas the new code prefers a compatibility mode if available. Using compatibility mode preferentially means that we're more likely to be able to migrate the guest to a similar but not identical host. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31prep: add IBM RS/6000 7020 (40p) machine emulationHervé Poussineau1-0/+230
Machine supports both Open Hack'Ware and OpenBIOS. Open Hack'Ware is the default because OpenBIOS is currently unable to boot PReP boot partitions or PReP kernels. Signed-off-by: Hervé Poussineau <hpoussin@reactos.org> [dwg: Correct compile failure with KVM located by Thomas Huth] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31prep: add IBM RS/6000 7020 (40p) memory controllerHervé Poussineau3-0/+240
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> [dwg: Added CONFIG_RS6000_MC to ppc64 or it breaks testcases] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31prep: add PReP System I/OHervé Poussineau3-0/+308
This device is a partial duplicate of System I/O device available in hw/ppc/prep.c This new one doesn't have all the Motorola-specific registers. The old one should be deprecated and removed with the 'prep' machine. Partial documentation available at ftp://ftp.software.ibm.com/rs6000/technology/spec/srp1_1.exe section 6.1.5 (I/O Device Mapping) Signed-off-by: Hervé Poussineau <hpoussin@reactos.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31hw/ppc: QOM'ify spapr_vio.cxiaoqiang zhao1-10/+0
Drop the old and empty SysBus init Signed-off-by: xiaoqiang zhao <zxq_yx_007@163.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31hw/ppc: QOM'ify ppce500_spin.cxiaoqiang zhao1-10/+8
Drop the old SysBus init function and use instance_init Signed-off-by: xiaoqiang zhao <zxq_yx_007@163.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31hw/ppc: QOM'ify e500.cxiaoqiang zhao1-13/+4
Drop the old SysBus init function and use instance_init Signed-off-by: xiaoqiang zhao <zxq_yx_007@163.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31ppc: Rewrite ppc_get_compat_smt_threads()David Gibson1-4/+4
To continue consolidation of compatibility mode information, this rewrites the ppc_get_compat_smt_threads() function using the table of compatiblity modes in target-ppc/compat.c. It's not a direct replacement, the new ppc_compat_max_threads() function has simpler semantics - it just returns the number of threads the cpu model has, taking into account any compatiblity mode it is in. This no longer takes into account kvmppc_smt_threads() as the previous version did. That check wasn't useful because we check in ppc_cpu_realizefn() that CPUs aren't instantiated with more threads than kvm allows (or if we didn't things will already be broken and this won't make it any worse). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-01-31pseries: Add pseries-2.9 machine typeDavid Gibson1-2/+21
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
2017-01-31prep: do not use global variable to access nvramHervé Poussineau1-2/+2
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31hw/ppc/spapr: Fix boot path of usb-host storage devicesThomas Huth1-0/+13
When passing through an USB storage device to a pseries guest, it is currently not possible to automatically boot from the device if the "bootindex" property has been specified, too (e.g. when using "-device nec-usb-xhci -device usb-host,hostbus=1,hostaddr=2,bootindex=0" at the command line). The problem is that QEMU builds a device tree path like "/pci@800000020000000/usb@0/usb-host@1" and passes it to SLOF in the /chosen/qemu,boot-list property. SLOF, however, probes the USB device, recognizes that it is a storage device and thus changes its name to "storage", and additionally adds a child node for the SCSI LUN, so the correct boot path in SLOF is something like "/pci@800000020000000/usb@0/storage@1/disk@101000000000000" instead. So when we detect an USB mass storage device with SCSI interface, we've got to adjust the firmware boot-device path properly that SLOF can automatically boot from the device. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1354177 Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31ppc/spapr: implement H_SIGNAL_SYS_RESETNicholas Piggin2-2/+43
The H_SIGNAL_SYS_RESET hcall allows a guest CPU to raise a system reset exception on CPUs within the same guest -- all CPUs, all-but-self, or a specific CPU (including self). This has not made its way to a PAPR release yet, but we have an hcall number assigned. H_SIGNAL_SYS_RESET = 0x380 Syntax: hcall(uint64 H_SIGNAL_SYS_RESET, int64 target); Generate a system reset NMI on the threads indicated by target. Values for target: -1 = target all online threads including the caller -2 = target all online threads except for the caller All other negative values: reserved Positive values: The thread to be targeted, obtained from the value of the "ibm,ppc-interrupt-server#s" property of the CPU in the OF device tree. Semantics: - Invalid target: return H_Parameter. - Otherwise: Generate a system reset NMI on target thread(s), return H_Success. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-01-31ppc: Rename cpu_version to compat_pvrDavid Gibson2-17/+17
The 'cpu_version' field in PowerPCCPU is badly named. It's named after the 'cpu-version' device tree property where it is advertised, but that meaning may not be obvious in most places it appears. Worse, it doesn't even really correspond to that device tree property. The property contains either the processor's PVR, or, if the CPU is running in a compatibility mode, a special "logical PVR" representing which mode. Rename the cpu_version field, and a number of related variables to compat_pvr to make this clearer. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Thomas Huth <thuth@redhat.com>
2017-01-31ppc: Clean up and QOMify hypercall emulationDavid Gibson2-3/+6
The pseries machine type is a bit unusual in that it runs a paravirtualized guest. The guest expects to interact with a hypervisor, and qemu emulates the functions of that hypervisor directly, rather than executing hypervisor code within the emulated system. To implement this in TCG, we need to intercept hypercall instructions and direct them to the machine's hypercall handlers, rather than attempting to perform a privilege change within TCG. This is controlled by a global hook - cpu_ppc_hypercall. This cleanup makes the handling a little cleaner and more extensible than a single global variable. Instead, each CPU to have hypercalls intercepted has a pointer set to a QOM object implementing a new virtual hypervisor interface. A method in that interface is called by TCG when it sees a hypercall instruction. It's possible we may want to add other methods in future. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-01-31pseries: Make cpu_update during CAS unconditionalDavid Gibson2-10/+3
spapr_h_cas_compose_response() includes a cpu_update parameter which controls whether it includes updated information on the CPUs in the device tree fragment returned from the ibm,client-architecture-support (CAS) call. Providing the updated information is essential when CAS has negotiated compatibility options which require different cpu information to be presented to the guest. However, it should be safe to provide in other cases (it will just override the existing data in the device tree with identical data). This simplifies the code by removing the parameter and always providing the cpu update information. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-01-31pseries: Always use core objects for CPU constructionDavid Gibson2-72/+90
Currently the pseries machine has two paths for constructing CPUs. On newer machine type versions, which support cpu hotplug, it constructs cpu core objects, which in turn construct CPU threads. For older machine versions it individually constructs the CPU threads. This division is going to make some future changes to the cpu construction harder, so this patch unifies them. Now cpu core objects are always created. This requires some updates to allow core objects to be created without a full complement of threads (since older versions allowed a number of cpus not a multiple of the threads-per-core). Likewise it needs some changes to the cpu core hot/cold plug path so as not to choke on the old machine types without hotplug support. For good measure, we move the cpu construction to its own subfunction, spapr_init_cpus(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>
2017-01-24hw: Fix typos found by codespellStefan Weil1-1/+1
Signed-off-by: Stefan Weil <sw@weilnetz.de> Acked-by: Alistair Francis <alistair.francis@xilinx.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2017-01-19kvm: move cpu synchronization codeVincent Palatin4-5/+5
Move the generic cpu_synchronize_ functions to the common hw_accel.h header, in order to prepare for the addition of a second hardware accelerator. Signed-off-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Message-Id: <f5c3cffe8d520011df1c2e5437bb814989b48332.1484045952.git.vpalatin@chromium.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-12-20Move target-* CPU file into a target/ folderThomas Huth6-8/+8
We've currently got 18 architectures in QEMU, and thus 18 target-xxx folders in the root folder of the QEMU source tree. More architectures (e.g. RISC-V, AVR) are likely to be included soon, too, so the main folder of the QEMU sources slowly gets quite overcrowded with the target-xxx folders. To disburden the main folder a little bit, let's move the target-xxx folders into a dedicated target/ folder, so that target-xxx/ simply becomes target/xxx/ instead. Acked-by: Laurent Vivier <laurent@vivier.eu> [m68k part] Acked-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> [tricore part] Acked-by: Michael Walle <michael@walle.cc> [lm32 part] Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x part] Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> [s390x part] Acked-by: Eduardo Habkost <ehabkost@redhat.com> [i386 part] Acked-by: Artyom Tarasenko <atar4qemu@gmail.com> [sparc part] Acked-by: Richard Henderson <rth@twiddle.net> [alpha part] Acked-by: Max Filippov <jcmvbkbc@gmail.com> [xtensa part] Reviewed-by: David Gibson <david@gibson.dropbear.id.au> [ppc part] Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> [cris&microblaze part] Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn> [unicore32 part] Signed-off-by: Thomas Huth <thuth@redhat.com>
2016-12-01spapr: fix default DRC state for coldplugged LMBsMichael Roth1-0/+5
Currently we set the initial isolation/allocation state for DRCs associated with coldplugged LMBs to ISOLATED/UNUSABLE, respectively, under the assumption that the guest will move this state to UNISOLATED/USABLE. In fact, this is only the case for LMBs added via hotplug. For coldplugged LMBs, the guest actually assumes the initial state to be UNISOLATED/USABLE. In practice, this only becomes an issue when we attempt to unplug one of these LMBs, where the guest kernel will issue an rtas-get-sensor-state call to check that the corresponding DRC is in an USABLE state before it will release the LMB back to QEMU. If the returned state is otherwise, the guest will assume no further action is needed, which bypasses the QEMU-side cleanup that occurs during the USABLE->UNUSABLE transition. This results in LMBs and their corresponding pc-dimm devices to stick around indefinitely. This patch fixes the issue by manually setting DRCs associated with cold-plugged LMBs to UNISOLATED/ALLOCATED, but leaving the hotplug state untouched. As it turns out, this is analogous to the handling for cold-plugged CPUs in spapr_core_plug(). Cc: qemu-ppc@nongnu.org Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Bharata B Rao <bharata@linux.vnet.ibm.com> Cc: Greg Kurz <gkurz@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-11-23spapr: Fix 2.7<->2.8 migration of PCI host bridgeDavid Gibson2-5/+33
daa2369 "spapr_pci: Add a 64-bit MMIO window" subtly broke migration from qemu-2.7 to the current version. It split the device's MMIO window into two pieces for 32-bit and 64-bit MMIO. The patch included backwards compatibility code to convert the old property into the new format. However, the property value was also transferred in the migration stream and compared with a (probably unwise) VMSTATE_EQUAL. So, the "raw" value from 2.7 is compared to the new style converted value from (pre-)2.8 giving a mismatch and migration failure. Along with the actual field that caused the breakage, there are several other ill-advised VMSTATE_EQUAL()s. To fix forwards migration, we read the values in the stream into scratch variables and ignore them, instead of comparing for equality. To fix backwards migration, we populate those scratch variables in pre_save() with adjusted values to match the old behaviour. To permit the eventual possibility of removing this cruft from the stream, we only include these compatibility fields if a new 'pre-2.8-migration' property is set. We clear it on the pseries-2.8 machine type, which obviously can't be migrated backwards, but set it on earlier machine type versions. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2016-11-23Revert "spapr: Fix migration of PCI host bridges from qemu-2.7"David Gibson1-12/+6
This reverts commit 9b54ca0ba781012eeea4237b7c4832ba2ea81d89. The commit above corrected a migration breakage between qemu-2.7 and qemu-2.8. However it did so by advancing the migration version for the PCI host bridge, which obviously breaks migration backwards to earlier qemu versions. Although it's not totally essential, we'd like to maintain the possibility for backwards migration, so revert the change in preparation for a better fix. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2016-11-23target-ppc: Allow eventual removal of old migration mistakesDavid Gibson1-0/+5
Until very recently, the vmstate for ppc cpus included some poorly thought out VMSTATE_EQUAL() components, that can easily break migration compatibility, and did so between qemu-2.6 and later versions. A hack was recently added which fixes this migration breakage, but it leaves the unhelpful cruft of these fields in the migration stream. This patch adds a new cpu property allowing these fields to be removed from the stream entirely. For the pseries-2.8 machine type - which comes after the fix - and for all non-pseries machine types - which aren't mature enough to care about cross-version migration - we remove the fields from the stream. For pseries-2.7 and earlier, The migration hack remains in place, allowing backwards and forwards migration with the older machine types. This restricts the migration compatibility cruft to older machine types, and at least opens the possibility of eventually deprecating and removing it entirely. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2016-11-23spapr: migration support for CAS-negotiated option vectorsMichael Roth2-0/+78
With the additional of the OV5_HP_EVT option vector, we now have certain functionality (namely, memory unplug) that checks at run-time for whether or not the guest negotiated the option via CAS. Because we don't currently migrate these negotiated values, we are unable to unplug memory from a guest after it's been migrated until after the guest is rebooted and CAS-negotiation is repeated. This patch fixes this by adding CAS-negotiated options to the migration stream. We do this using a subsection, since the negotiated value of OV5_HP_EVT is the only option currently needed to maintain proper functionality for a running guest. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-11-16fw_cfg: move FW_CFG_NB_CPUS out of fw_cfg_init1()Igor Mammedov2-0/+2
PC will use this field in other way, so move it outside the common code so PC could set a different value, i.e. all CPUs regardless of where they are coming from (-smp X | -device cpu...). It's quick and dirty hack as it could be implemented in more generic way in MashineClass. But do it in simple way since only PC is affected so far. Later we can generalize it when another affected target gets support for -device cpu. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1479212236-183810-3-git-send-email-imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-11-15ppc/pnv: Fix fatal bug on 32-bit hostsDavid Gibson1-1/+1
If the pnv machine type is compiled on a 32-bit host, the unsigned long (host) type is 32-bit. This means that the hweight_long() used to calculate the number of allowed cores only considers the low 32 bits of the cores_mask variable, and can thus return 0 in some circumstances. This corrects the bug. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Suggested-by: Richard Henderson <rth@twiddle.net> [clg: replaced hweight_long() by ctpop64() ] Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
generated by cgit v1.1 at 2025-01-03 23:53:46 +0000