aboutsummaryrefslogtreecommitdiff
path: root/hw/ppc/spapr_rtas.c
AgeCommit message (Collapse)AuthorFilesLines
2021-06-03spapr: Set LPCR to current AIL mode when starting a new CPUNicholas Piggin1-5/+9
TCG does not keep track of AIL mode in a central place, it's based on the current LPCR[AIL] bits. Synchronize the new CPU's LPCR to the current LPCR in rtas_start_cpu(), similarly to the way the ILE bit is synchronized. Open-code the ILE setting as well now that the caller's LPCR is available directly, there is no need for the indirection. Without this, under both TCG and KVM, adding a POWER8/9/10 class CPU with a new core ID after a modern Linux has booted results in the new CPU's LPCR missing the LPCR[AIL]=0b11 setting that the other CPUs have. This can cause crashes and unexpected behaviour. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20210526091626.3388262-3-npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-06-03spapr: Remove stale comment about power-saving LPCR bitsNicholas Piggin1-1/+0
Commit 47a9b551547 ("spapr: Clean up handling of LPCR power-saving exit bits") moved this logic but did not remove the comment from the previous location. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20210526091626.3388262-2-npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-05Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.1-20210504' ↵Peter Maydell1-0/+2
into staging ppc patch queue 2021-05-04 Here's the first ppc pull request for qemu-6.1. It has a wide variety of stuff accumulated during the 6.0 freeze. Highlights are: * Multi-phase reset cleanups for PAPR * Preliminary cleanups towards allowing !CONFIG_TCG for the ppc target * Cleanup of AIL logic and extension to POWER10 * Further improvements to handling of hot unplug failures on PAPR * Allow much larger numbers of CPU on pseries * Support for the H_SCM_HEALTH hypercall * Add support for the Pegasos II board * Substantial cleanup to hflag handling * Assorted minor fixes and cleanups # gpg: Signature made Tue 04 May 2021 06:52:39 BST # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dg-gitlab/tags/ppc-for-6.1-20210504: (46 commits) hw/ppc/pnv_psi: Use device_cold_reset() instead of device_legacy_reset() hw/ppc/spapr_vio: Reset TCE table object with device_cold_reset() hw/intc/spapr_xive: Use device_cold_reset() instead of device_legacy_reset() target/ppc: removed VSCR from SPR registration target/ppc: Reduce the size of ppc_spr_t target/ppc: Clean up _spr_register et al target/ppc: Add POWER10 exception model target/ppc: rework AIL logic in interrupt delivery target/ppc: move opcode table logic to translate.c target/ppc: code motion from translate_init.c.inc to gdbstub.c spapr_drc.c: handle hotunplug errors in drc_unisolate_logical() spapr.h: increase FDT_MAX_SIZE spapr.c: do not use MachineClass::max_cpus to limit CPUs ppc: Rename current DAWR macros and variables target/ppc: POWER10 supports scv target/ppc: Fix POWER9 radix guest HV interrupt AIL behaviour docs/system: ppc: Add documentation for ppce500 machine roms/u-boot: Bump ppce500 u-boot to v2021.04 to fix broken pci support roms/Makefile: Update ppce500 u-boot build directory name ppc/spapr: Add support for implement support for H_SCM_HEALTH ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-05-04hw/ppc/spapr_rtas: Update hflags after setting msrRichard Henderson1-0/+2
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210315184615.1985590-16-richard.henderson@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-02Do not include cpu.h if it's not really necessaryThomas Huth1-1/+0
Stop including cpu.h in files that don't need it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-4-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-02Do not include hw/boards.h if it's not really necessaryThomas Huth1-1/+0
Stop including hw/boards.h in files that don't need it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-3-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-01-19spapr_rtas.c: fix identation of rtas_ibm_suspend_me() argsDaniel Henrique Barboza1-3/+3
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210114180628.1675603-5-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-07-27pseries: fix kvmppc_set_fwnmi()Laurent Vivier1-1/+1
QEMU issues the ioctl(KVM_CAP_PPC_FWNMI) on the first vCPU. If the first vCPU is currently running, the vCPU mutex is held and the ioctl() cannot be done and waits until the mutex is released. This never happens and the VM is stuck. To avoid this deadlock, issue the ioctl on the same vCPU doing the RTAS call. The problem can be reproduced by booting a guest with several vCPUs (the probability to have the problem is (n - 1) / n, n = # of CPUs), and then by triggering a kernel crash with "echo c >/proc/sysrq-trigger". On the reboot, the kernel hangs after: ... [ 0.000000] ----------------------------------------------------- [ 0.000000] ppc64_pft_size = 0x0 [ 0.000000] phys_mem_size = 0x48000000 [ 0.000000] dcache_bsize = 0x80 [ 0.000000] icache_bsize = 0x80 [ 0.000000] cpu_features = 0x0001c06f8f4f91a7 [ 0.000000] possible = 0x0003fbffcf5fb1a7 [ 0.000000] always = 0x00000003800081a1 [ 0.000000] cpu_user_features = 0xdc0065c2 0xaee00000 [ 0.000000] mmu_features = 0x3c006041 [ 0.000000] firmware_features = 0x00000085455a445f [ 0.000000] physical_start = 0x8000000 [ 0.000000] ----------------------------------------------------- [ 0.000000] numa: NODE_DATA [mem 0x47f33c80-0x47f3ffff] Fixes: ec010c00665b ("ppc/spapr: KVM FWNMI should not be enabled until guest requests it") Cc: npiggin@gmail.com Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20200724083533.281700-1-lvivier@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-04-07ppc/spapr: Add FWNMI machine check delivery warningsNicholas Piggin1-0/+3
Add some messages which explain problems and guest misbehaviour that may be difficult to diagnose in rare cases of machine checks. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200325142906.221248-4-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-04-07ppc/spapr: KVM FWNMI should not be enabled until guest requests itNicholas Piggin1-0/+7
The KVM FWNMI capability should be enabled with the "ibm,nmi-register" rtas call. Although MCEs from KVM will be delivered as architected interrupts to the guest before "ibm,nmi-register" is called, KVM has different behaviour depending on whether the guest has enabled FWNMI (it attempts to do more recovery on behalf of a non-FWNMI guest). Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200325142906.221248-2-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17ppc/spapr: Ignore common "ibm,nmi-interlock" Linux bugNicholas Piggin1-2/+12
Linux kernels call "ibm,nmi-interlock" in their system reset handlers contrary to PAPR. Returning an error because the CPU does not hold the interlock here causes Linux to print warning messages. PowerVM returns success in this case, so do the same for now. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200316142613.121089-9-npiggin@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17ppc/spapr: Add FWNMI System Reset stateNicholas Piggin1-1/+13
The FWNMI option must deliver system reset interrupts to their registered address, and there are a few constraints on the handler addresses specified in PAPR. Add the system reset address state and checks. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200316142613.121089-4-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviwed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17ppc/spapr: Change FWNMI namesNicholas Piggin1-8/+9
The option is called "FWNMI", and it involves more than just machine checks, also machine checks can be delivered without the FWNMI option, so re-name various things to reflect that. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200316142613.121089-3-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-03-17ppc/spapr: Move GPRs setup to one placeAlexey Kardashevskiy1-1/+1
At the moment "pseries" starts in SLOF which only expects the FDT blob pointer in r3. As we are going to introduce a OpenFirmware support in QEMU, we will be booting OF clients directly and these expect a stack pointer in r1, Linux looks at r3/r4 for the initramdisk location (although vmlinux can find this from the device tree but zImage from distro kernels cannot). This extends spapr_cpu_set_entry_state() to take more registers. This should cause no behavioral change. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20200310050733.29805-2-aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-21spapr/rtas: Print message from "ibm,os-term"Alexey Kardashevskiy1-0/+7
The "ibm,os-term" RTAS call has a single parameter which is a pointer to a message from the guest kernel about the termination cause; this prints it. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20200203032044.118585-1-aik@ozlabs.ru> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-03migration: Include migration support for machine check handlingAravinda Prasad1-0/+2
This patch includes migration support for machine check handling. Especially this patch blocks VM migration requests until the machine check error handling is complete as these errors are specific to the source hardware and is irrelevant on the target hardware. Signed-off-by: Aravinda Prasad <arawinda.p@gmail.com> [Do not set FWNMI cap in post_load, now its done in .apply hook] Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com> Message-Id: <20200130184423.20519-7-ganeshgr@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-03ppc: spapr: Handle "ibm,nmi-register" and "ibm,nmi-interlock" RTAS callsAravinda Prasad1-0/+59
This patch adds support in QEMU to handle "ibm,nmi-register" and "ibm,nmi-interlock" RTAS calls. The machine check notification address is saved when the OS issues "ibm,nmi-register" RTAS call. This patch also handles the case when multiple processors experience machine check at or about the same time by handling "ibm,nmi-interlock" call. In such cases, as per PAPR, subsequent processors serialize waiting for the first processor to issue the "ibm,nmi-interlock" call. The second processor that also received a machine check error waits till the first processor is done reading the error log. The first processor issues "ibm,nmi-interlock" call when the error log is consumed. Signed-off-by: Aravinda Prasad <arawinda.p@gmail.com> [Register fwnmi RTAS calls in core_rtas_register_types() where other RTAS calls are registered] Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com> Message-Id: <20200130184423.20519-6-ganeshgr@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-03target/ppc: Build rtas error log upon an MCEAravinda Prasad1-0/+26
Upon a machine check exception (MCE) in a guest address space, KVM causes a guest exit to enable QEMU to build and pass the error to the guest in the PAPR defined rtas error log format. This patch builds the rtas error log, copies it to the rtas_addr and then invokes the guest registered machine check handler. The handler in the guest takes suitable action(s) depending on the type and criticality of the error. For example, if an error is unrecoverable memory corruption in an application inside the guest, then the guest kernel sends a SIGBUS to the application. For recoverable errors, the guest performs recovery actions and logs the error. Signed-off-by: Aravinda Prasad <arawinda.p@gmail.com> [Assume SLOF has allocated enough room for rtas error log] Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200130184423.20519-5-ganeshgr@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-01-24hw/ppc/spapr_rtas: Remove local variablePhilippe Mathieu-Daudé1-3/+2
We only access this variable in the RTAS_SYSPARM_SPLPAR_CHARACTERISTICS case. Use it in place and remove the local declaration. Suggested-by: Greg Kurz <groug@kaod.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200121110349.25842-4-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24hw/ppc/spapr_rtas: Access MachineState via SpaprMachineState argumentPhilippe Mathieu-Daudé1-1/+1
We received a SpaprMachineState argument. Since SpaprMachineState inherits of MachineState, use it instead of calling qdev_get_machine. Reviewed-by: Greg Kurz <groug@kaod.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200121110349.25842-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-24hw/ppc/spapr_rtas: Use local MachineState variablePhilippe Mathieu-Daudé1-1/+1
Since we have the MachineState already available locally, use it instead of the global current_machine. Reviewed-by: Greg Kurz <groug@kaod.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200121110349.25842-2-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-04spapr: Stop providing RTAS blobAlexey Kardashevskiy1-41/+0
SLOF implements one itself so let's remove it from QEMU. It is one less image and simpler setup as the RTAS blob never stays in its initial place anyway as the guest OS always decides where to put it. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-29powerpc/spapr: Add host threads parameter to ibm,get_system_parameterSuraj Jitindar Singh1-0/+15
The ibm,get_system_parameter rtas call is used by the guest to retrieve data relating to certain parameters of the system. The SPLPAR characteristics option (token 20) is used to determine characteristics of the environment in which the lpar will run. It may be useful for a guest to know the number of physical host threads present on the underlying system where it is being run. Add the characteristic "HostThrs" to the SPLPAR Characteristics ibm,get_system_parameter rtas call to expose this information to a guest. Add a n_host_threads property to the processor class which is then used to retrieve this information and define it for POWER8 and POWER9. Other processors will default to 0 and the charateristic won't be added. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Message-Id: <20190827045751.22123-1-sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-21spapr: Implement ibm,suspend-meNicholas Piggin1-0/+32
This has been useful to modify and test the Linux pseries suspend code but it requires modification to the guest to call it (due to being gated by other unimplemented features). It is not otherwise used by Linux yet, but work is slowly progressing there. This allows a (lightly modified) guest kernel to suspend with `echo mem > /sys/power/state` and be resumed with system_wakeup monitor command. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20190722061752.22114-2-npiggin@gmail.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-16sysemu: Split sysemu/runstate.h off sysemu/sysemu.hMarkus Armbruster1-0/+2
sysemu/sysemu.h is a rather unfocused dumping ground for stuff related to the system-emulator. Evidence: * It's included widely: in my "build everything" tree, changing sysemu/sysemu.h still triggers a recompile of some 1100 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h, down from 5400 due to the previous two commits). * It pulls in more than a dozen additional headers. Split stuff related to run state management into its own header sysemu/runstate.h. Touching sysemu/sysemu.h now recompiles some 850 objects. qemu/uuid.h also drops from 1100 to 850, and qapi/qapi-types-run-state.h from 4400 to 4200. Touching new sysemu/runstate.h recompiles some 500 objects. Since I'm touching MAINTAINERS to add sysemu/runstate.h anyway, also add qemu/main-loop.h. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190812052359.30071-30-armbru@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> [Unbreak OS-X build]
2019-08-16Include hw/qdev-properties.h lessMarkus Armbruster1-1/+0
In my "build everything" tree, changing hw/qdev-properties.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). Many places including hw/qdev-properties.h (directly or via hw/qdev.h) actually need only hw/qdev-core.h. Include hw/qdev-core.h there instead. hw/qdev.h is actually pointless: all it does is include hw/qdev-core.h and hw/qdev-properties.h, which in turn includes hw/qdev-core.h. Replace the remaining uses of hw/qdev.h by hw/qdev-properties.h. While there, delete a few superfluous inclusions of hw/qdev-core.h. Touching hw/qdev-properties.h now recompiles some 1200 objects. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190812052359.30071-22-armbru@redhat.com>
2019-07-05hw/ppc: Replace global smp variables with machine smp propertiesLike Xu1-1/+3
The global smp variables in ppc are replaced with smp machine properties. A local variable of the same name would be introduced in the declaration phase if it's used widely in the context OR replace it on the spot if it's only used once. No semantic changes. Signed-off-by: Like Xu <like.xu@linux.intel.com> Message-Id: <20190518205428.90532-5-like.xu@linux.intel.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-05-29target/ppc: Set PSSCR_EC on cpu halt to prevent spurious wakeupSuraj Jitindar Singh1-1/+5
The processor stop status and control register (PSSCR) is used to control the power saving facilities of the thread. The exit criterion bit (EC) is used to specify whether the thread should be woken by any interrupt (EC == 0) or only an interrupt enabled in the LPCR to wake the thread (EC == 1). The rtas facilities start-cpu and self-stop are used to transition a vcpu between the stopped and running states. When a vcpu is stopped it may only be started again by the start-cpu rtas call. Currently a vcpu in the stopped state will start again whenever an interrupt comes along due to PSSCR_EC being cleared, and while this is architecturally correct for a hardware thread, a vcpu is expected to only be woken by calling start-cpu. This means when performing a reboot on a tcg machine that the secondary threads will restart while the primary is still in slof, this is unsupported and causes call traces like: SLOF ********************************************************************** QEMU Starting Build Date = Jan 14 2019 18:00:39 FW Version = git-a5b428e1c1eae703 Press "s" to enter Open Firmware. qemu: fatal: Trying to deliver HV exception (MSR) 70 with no HV support NIP 6d61676963313230 LR 000000003dbe0308 CTR 6d61676963313233 XER 0000000000000000 CPU#1 MSR 0000000000000000 HID0 0000000000000000 HF 0000000000000000 iidx 3 didx 3 TB 00000026 115746031956 DECR 18446744073326238463 GPR00 000000003dbe0308 000000003e669fe0 000000003dc10700 0000000000000003 GPR04 000000003dc62198 000000003dc62178 000000003dc0ea48 0000000000000030 GPR08 000000003dc621a8 0000000000000018 000000003e466008 000000003dc50700 GPR12 c00000000093a4e0 c00000003ffff300 c00000003e533f90 0000000000000000 GPR16 0000000000000000 0000000000000000 000000003e466010 000000003dc0b040 GPR20 0000000000008000 000000000000f003 0000000000000006 000000003e66a050 GPR24 000000003dc06400 000000003dc0ae70 0000000000000003 000000000000f001 GPR28 000000003e66a060 ffffffffffffffff 6d61676963313233 0000000000000028 CR 28000222 [ E L - - - E E E ] RES ffffffffffffffff FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR08 0000000000000000 0000000000000000 0000000000000000 00000000311825e0 FPR12 00000000311825e0 0000000000000000 0000000000000000 0000000000000000 FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPSCR 0000000000000000 SRR0 000000003dbe06b0 SRR1 0000000000080000 PVR 00000000004e1200 VRSAVE 0000000000000000 SPRG0 000000003dbe0308 SPRG1 000000003e669fe0 SPRG2 00000000000000d8 SPRG3 000000003dbe0308 SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000 HSRR0 6d61676963313230 HSRR1 0000000000000000 CFAR 000000003dbe3e64 LPCR 0000000004020008 PTCR 0000000000000000 DAR 0000000000000000 DSISR 0000000000000000 Aborted (core dumped) To fix this, set the PSSCR_EC bit when a vcpu is stopped to disable it from coming back online until the start-cpu rtas call is made. Fixes: 21c0d66a9c99 ("target/ppc: Fix support for "STOP light" states on POWER9") Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Message-Id: <20190516005744.24366-1-sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-04-26spapr/rtas: modify spapr_rtas_register() to remove RTAS handlersCédric Le Goater1-1/+1
Removing RTAS handlers will become necessary when the new pseries machine supporting multiple interrupt mode is introduced. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190321144914.19934-9-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12spapr: Use CamelCase properlyDavid Gibson1-15/+15
The qemu coding standard is to use CamelCase for type and structure names, and the pseries code follows that... sort of. There are quite a lot of places where we bend the rules in order to preserve the capitalization of internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR". That was a bad idea - it frequently leads to names ending up with hard to read clusters of capital letters, and means they don't catch the eye as type identifiers, which is kind of the point of the CamelCase convention in the first place. In short, keeping type identifiers look like CamelCase is more important than preserving standard capitalization of internal "words". So, this patch renames a heap of spapr internal type names to a more standard CamelCase. In addition to case changes, we also make some other identifier renames: VIOsPAPR* -> SpaprVio* The reverse word ordering was only ever used to mitigate the capital cluster, so revert to the natural ordering. VIOsPAPRVTYDevice -> SpaprVioVty VIOsPAPRVLANDevice -> SpaprVioVlan Brevity, since the "Device" didn't add useful information sPAPRDRConnector -> SpaprDrc sPAPRDRConnectorClass -> SpaprDrcClass Brevity, and makes it clearer this is the same thing as a "DRC" mentioned in many other places in the code This is 100% a mechanical search-and-replace patch. It will, however, conflict with essentially any and all outstanding patches touching the spapr code. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-02-26target/ppc/spapr: Set LPCR:HR when using Radix modeBenjamin Herrenschmidt1-3/+3
The HW relies on LPCR:HR along with the PATE to determine whether to use Radix or Hash mode. In fact it uses LPCR:HR more commonly than the PATE. For us, it's also more efficient to do so, especially since unlike the HW we do not maintain a cache of the current PATE and HV PATE in a generic place. Prepare the grounds for that by ensuring that LPCR:HR is set properly on SPAPR machines. Another option would have been to use a callback to get the PATE but this gets messy when implementing bare metal support, it's much simpler (and faster) to use LPCR. Since existing migration streams may not have it, fix it up in spapr_post_load() as well based on the pseudo-PATE entry that we keep. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190215170029.15641-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-09-05target/ppc/kvm: set vcpu as online/offlineNikunj A Dadhania1-0/+2
Set the newly added register(KVM_REG_PPC_ONLINE) to indicate if the vcpu is online(1) or offline(0) KVM will use this information to set the RWMR register, which controls the PURR and SPURR accumulation. CC: paulus@samba.org Signed-off-by: Nikunj A Dadhania <nikunj@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-07-02hw/ppc: Use the IEC binary prefix definitionsPhilippe Mathieu-Daudé1-1/+1
It eases code review, unit is explicit. Patch generated using: $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/ and modified manually. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20180625124238.25339-33-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-07-02hw: Use IEC binary prefix definitions from "qemu/units.h"Philippe Mathieu-Daudé1-1/+1
Code change produced with: $ git ls-files | egrep '\.[ch]$' | \ xargs sed -i -e 's/\(\W[KMGTPE]\)_BYTE/\1iB/g' Suggested-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> (ppc parts) Message-Id: <20180625124238.25339-6-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-05-04spapr: Clean up handling of LPCR power-saving exit bitsDavid Gibson1-1/+1
To prevent spurious wakeups on cpus that are supposed to be disabled, we need to clear the LPCR bits which control certain wakeup events. spapr_cpu_reset() has separate cases here for boot and non-boot (initially inactive) cpus. rtas_start_cpu() then turns the LPCR bits on when the non-boot cpus are activated. But explicit checks against first_cpu are not how we usually do things: instead spapr_cpu_reset() generally sets things up for non-boot (inactive) cpus, then spapr_machine_reset() and/or rtas_start_cpu() override as necessary. So, do that instead. Because the LPCR activation is identical for boot cpus and non-boot cpus just activated with rtas_start_cpu() we can put the code common in spapr_cpu_set_entry_state(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org>
2018-05-04target/ppc: Delay initialization of LPCR_UPRT for secondary cpusDavid Gibson1-0/+12
In cpu_ppc_set_papr() the UPRT and GTSE bits of the LPCR default value are initialized based on on ppc64_radix_guest(). Which seems reasonable, except that ppc64_radix_guest() is based on spapr->patb_entry which is only set up in spapr_machine_reset, called _after_ cpu_ppc_set_papr() for boot cpus. Well, and the fact that modifying the SPR default value for an instance rather than a class is kind of yucky. The initialization here is really only necessary or valid for hotplugged cpus; the base cpu initialization already sets a value that's good enough for the boot cpus until the guest uses an hcall to configure it's preferred MMU mode. So, move this initialization to the rtas_start_cpu() path, at which point ppc64_radix_guest() will have a sensible value, to make sure secondary cpus come up in an MMU mode matching the existing cpus. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org>
2018-05-04spapr: Make a helper to set up cpu entry point stateDavid Gibson1-4/+2
Under PAPR, only the boot CPU is active when the system starts. Other cpus must be explicitly activated using an RTAS call. The entry state for the boot and secondary cpus isn't identical, but it has some things in common. We're going to add a bit more common setup later, too, so to simplify make a helper which sets up the common entry state for both boot and secondary cpu threads. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-05-04spapr: Remove unhelpful helpers from rtas_start_cpu()David Gibson1-24/+14
rtas_start_cpu() calls spapr_cpu_update_tb_offset() and spapr_cpu_set_endianness() to initialize certain things in the new cpu's state. This is the only caller of those helpers, and they're each only a few lines long, so we might as well just fold them into the caller. In addition, those helpers initialize state on the new cpu to match that of the first cpu. That will generally work, but might be at least logically incorrect if the first cpu has been set offline by the guest. So, instead base the state on that of the cpu invoking the RTAS call, which is obviously active already. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-05-04spapr: Clean up rtas_start_cpu() & rtas_stop_self()David Gibson1-34/+32
This makes several minor cleanups to these functions: * Follow usual convention of an early exit on error, rather than having most of the body in an if * Clearer naming of cpu and cpu_. Now callcpu is the cpu from which the RTAS call is invoked, newcpu is the cpu which we're starting * Use cpu_synchronize_state() instead of kvm_cpu_synchronize_state() directly * Remove pointless comment describing what cpu_synchronize_state() does * Use ppc_store_lpcr() instead of directly writing the register field Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
2018-03-02Include less of the generated modular QAPI headersMarkus Armbruster1-1/+0
In my "build everything" tree, a change to the types in qapi-schema.json triggers a recompile of about 4800 out of 5100 objects. The previous commit split up qmp-commands.h, qmp-event.h, qmp-visit.h, qapi-types.h. Each of these headers still includes all its shards. Reduce compile time by including just the shards we actually need. To illustrate the benefits: adding a type to qapi/migration.json now recompiles some 2300 instead of 4800 objects. The next commit will improve it further. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180211093607.27351-24-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> [eblake: rebase to master] Signed-off-by: Eric Blake <eblake@redhat.com>
2018-01-20spapr: fix device tree properties when using compatibility modeGreg Kurz1-9/+0
Commit 51f84465dd98 changed the compatility mode setting logic: - machine reset only sets compatibility mode for the boot CPU - compatibility mode is set for other CPUs when they are put online by the guest with the "start-cpu" RTAS call This causes a regression for machines started with max-compat-cpu: the device tree nodes related to secondary CPU cores contain wrong "cpu-version" and "ibm,pa-features" values, as shown below. Guest started on a POWER8 host with: -smp cores=2 -machine pseries,max-cpu-compat=compat7 ibm,pa-features = [18 00 f6 3f c7 c0 80 f0 80 00 00 00 00 00 00 00 00 00 80 00 80 00 80 00 00 00]; cpu-version = <0x4d0200>; ^^^ second CPU core ibm,pa-features = <0x600f63f 0xc70080c0>; cpu-version = <0xf000003>; ^^^ boot CPU core The second core is advertised in raw POWER8 mode. This happens because CAS assumes all CPUs to have the same compatibility mode. Since the boot CPU already has the requested compatibility mode, the CAS code does not set it for the secondary one, and exposes the bogus device tree properties in in the CAS response to the guest. A similar situation is observed when hot-plugging a CPU core. The related device tree properties are generated and exposed to guest with the "ibm,configure-connector" RTAS before "start-cpu" is called. The CPU core is advertised to the guest in raw mode as well. It both cases, it boils down to the fact that "start-cpu" happens too late. This can be fixed globally by propagating the compatibility mode of the boot CPU to the other CPUs during reset. For this to work, the compatibility mode of the boot CPU must be set before the machine code actually resets all CPUs. It is not needed to set the compatibility mode in "start-cpu" anymore, so the code is dropped. Fixes: 51f84465dd98 Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-10spapr: Correct compatibility mode setting for hotplugged CPUsDavid Gibson1-0/+9
Currently the pseries machine sets the compatibility mode for the guest's cpus in two places: 1) at machine reset and 2) after CAS negotiation. This means that if we set or negotiate a compatiblity mode, then hotplug a cpu, the hotplugged cpu doesn't get the right mode set and will incorrectly have the full native features. To correct this, we set the compatibility mode on a cpu when it is brought online with the 'start-cpu' RTAS call. Given that we no longer need to set the compatibility mode on all CPUs at machine reset, so we change that to only set the mode for the boot cpu. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Tested-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
2017-12-15spapr/rtas: do not reset the MSR in stop-self commandCédric Le Goater1-10/+0
When a CPU is stopped with the 'stop-self' RTAS call, its state 'halted' is switched to 1 and, in this case, the MSR is not taken into account anymore in the cpu_has_work() routine. Only the pending hardware interrupts are checked with their LPCR:PECE* enablement bit. The CPU is now also protected from the decrementer interrupt by the LPCR:PECE* bits which are disabled in the 'stop-self' RTAS call. Reseting the MSR is pointless. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-12-15spapr/rtas: disable the decrementer interrupt when a CPU is unpluggedCédric Le Goater1-0/+11
When a CPU is stopped with the 'stop-self' RTAS call, its state 'halted' is switched to 1 and, in this case, the MSR is not taken into account anymore in the cpu_has_work() routine. Only the pending hardware interrupts are checked with their LPCR:PECE* enablement bit. If the DECR timer fires after 'stop-self' is called and before the CPU 'stop' state is reached, the nearly-dead CPU will have some work to do and the guest will crash. This case happens very frequently with the not yet upstream P9 XIVE exploitation mode. In XICS mode, the DECR is occasionally fired but after 'stop' state, so no work is to be done and the guest survives. I suspect there is a race between the QEMU mainloop triggering the timers and the TCG CPU thread but I could not quite identify the root cause. To be safe, let's disable in the LPCR all the exceptions which can cause an exit while the CPU is in power-saving mode and reenable them when the CPU is started. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-08ppc: spapr: Make VCPU ID handling private to SPAPRSam Bobroff1-2/+2
The concept of a VCPU ID that differs from the CPU's index (cpu->cpu_index) exists only within SPAPR machines so, move the functions ppc_get_vcpu_id() and ppc_get_cpu_by_vcpu_id() into spapr.c and rename them appropriately. Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-08ppc: spapr: Rename cpu_dt_id to vcpu_idSam Bobroff1-2/+2
This field actually records the VCPU ID used by KVM and, although the value is also used in the device tree it is primarily the VCPU ID so rename it as such. Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com> [dwg: Updated comment missed in cpu.h] Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-06-08pseries: Correct panic behaviour for pseries machine typeDavid Gibson1-5/+2
The pseries machine type doesn't usually use the 'pvpanic' device as such, because it has a firmware/hypervisor facility with roughly the same purpose. The 'ibm,os-term' RTAS call notifies the hypervisor that the guest has crashed. Our implementation of this call was sending a GUEST_PANICKED qmp event; however, it was not doing the other usual panic actions, making its behaviour different from pvpanic for no good reason. To correct this, we should call qemu_system_guest_panicked() rather than directly sending the panic event. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com>
2017-06-06spapr: Move DRC RTAS calls into spapr_drc.cDavid Gibson1-304/+0
Currently implementations of the RTAS calls related to DRCs are in spapr_rtas.c. They belong better in spapr_drc.c - that way they're closer to related code, and we'll be able to make some more things local. spapr_rtas.c was intended to contain the RTAS infrastructure and core calls that don't belong anywhere else, not every RTAS implementation. Code motion only. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Daniel Barboza <danielhb@linux.vnet.ibm.com>
2017-06-02Remove/replace sysemu/char.h inclusionMarc-André Lureau1-1/+0
Those are apparently unnecessary includes. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-05-23shutdown: Add source information to SHUTDOWN and RESETEric Blake1-2/+2
Time to wire up all the call sites that request a shutdown or reset to use the enum added in the previous patch. It would have been less churn to keep the common case with no arguments as meaning guest-triggered, and only modified the host-triggered code paths, via a wrapper function, but then we'd still have to audit that I didn't miss any host-triggered spots; changing the signature forces us to double-check that I correctly categorized all callers. Since command line options can change whether a guest reset request causes an actual reset vs. a shutdown, it's easy to also add the information to reset requests. Signed-off-by: Eric Blake <eblake@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> [ppc parts] Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> [SPARC part] Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x parts] Message-Id: <20170515214114.15442-5-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>