aboutsummaryrefslogtreecommitdiff
path: root/target/ppc/cpu_init.c
AgeCommit message (Collapse)Author
2022-02-18target/ppc: cpu_init: Move e300 SPR registration into a functionFabiano Rosas
This is done to improve init_proc readability and to make subsequent patches that touch this code a bit cleaner. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-17-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Move 755 L2 cache SPRs into a functionFabiano Rosas
This is just to have 755-specific registers contained into a function, intead of leaving them open-coded in init_proc_755. It makes init_proc easier to read and keeps later patches that touch this code a bit cleaner. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-16-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Deduplicate 7xx SPR registrationFabiano Rosas
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-15-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Deduplicate 745/755 SPR registrationFabiano Rosas
The 745 and 755 can share the HID registration, so move it all into register_755_sprs, which applies for both CPUs. Also rename that function to register_745_sprs, since the 745 is the earliest of the two. This will help with separating 755-specific registers in a subsequent patch. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-14-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Deduplicate 604 SPR registrationFabiano Rosas
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-13-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Deduplicate 603 SPR registrationFabiano Rosas
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-12-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Deduplicate 440 SPR registrationFabiano Rosas
Move some of the 440 registers that are being repeated in the 440* CPUs to register_440_sprs. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-11-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Decouple 74xx SPR registration from 7xxFabiano Rosas
We're considering these two to be from different CPU families, so duplicate some code to keep them separate. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-10-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Decouple G2 SPR registration from 755Fabiano Rosas
We're considering these two to be in different CPU families (6xx and 7xx), so keep their SPR registration separate. The code was copied into register_G2_sprs and the common function was renamed to apply only to the 755. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-9-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Move G2 SPRs into register_G2_sprsFabiano Rosas
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-8-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Move 405 SPRs into register_405_sprsFabiano Rosas
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-7-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Avoid nested SPR register functionsFabiano Rosas
Make sure that every register_*_sprs function only has calls to spr_register* to register individual SPRs. Do not allow nesting. This makes the code easier to follow and a look at init_proc_* should suffice to know what SPRs a CPU has. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-6-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Move Timebase registration into the common functionFabiano Rosas
Now that the 601 was removed, all of our CPUs have a timebase, so that can be moved into the common function. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-5-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Group registration of generic SPRsFabiano Rosas
The top level init_proc calls register_generic_sprs but also registers some other SPRs outside of that function. Let's group everything into a single place. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-4-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Remove G2LE init codeFabiano Rosas
The G2LE CPU initialization code is the same as the G2. Use the latter for both. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-3-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-18target/ppc: cpu_init: Remove not implemented commentsFabiano Rosas
The /* XXX : not implemented */ comments all over cpu_init are confusing and ambiguous. Do they mean not implemented by QEMU, not implemented in a specific access mode? Not implemented by the CPU? Do they apply to just the register right after or to a whole block? Do they mean we have an action to take in the future to implement these? Are they only informative? Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220216162426.1885923-2-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-09target/ppc: Merge 7x5 and 7x0 exception model IDsFabiano Rosas
Since we've split the exception code by exception model, the exception model IDs are becoming less useful. These two can be merged. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Message-Id: <20220204173430.1457358-2-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-09target/ppc: Merge exception model IDs for 6xx CPUsFabiano Rosas
We don't need three separate exception model IDs for the 603, 604 and G2. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Message-Id: <20220203200957.1434641-2-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-09target/ppc: Remove PowerPC 601 CPUsCédric Le Goater
The PowerPC 601 processor is the first generation of processors to implement the PowerPC architecture. It was designed as a bridge processor and also could execute most of the instructions of the previous POWER architecture. It was found on the first Macs and IBM RS/6000 workstations. There is not much interest in keeping the CPU model of this POWER-PowerPC bridge processor. We have the 603 and 604 CPU models of the 60x family which implement the complete PowerPC instruction set. Cc: "Hervé Poussineau" <hpoussin@reactos.org> Cc: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Message-Id: <20220203142756.1302515-1-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-09target/ppc: Remove 440x4 CPUFabiano Rosas
This CPU was partially removed due to lack of support in 2017 by commit aef7796057 ("ppc: remove non implemented cpu models"). Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220128221611.1221715-1-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-28target/ppc: Remove support for the PowerPC 602 CPUCédric Le Goater
The 602 was derived from the PowerPC 603, for the gaming market it seems. It was hardly used and no firmware supporting the CPU could be found. Drop support. Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-28target/ppc: 405: Add missing MSR_ME bitFabiano Rosas
The 405 MSR has the Machine Check Enable bit. We're making use of it when dispatching Machine Check, so add the bit to the msr_mask. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220118184448.852996-3-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-28target/ppc: 405: Rename MSR_POW to MSR_WEFabiano Rosas
Bit 13 is the Wait State Enable bit. Give it its proper name. As far as I can see we don't do anything with MSR_POW for the 405, so this change has no effect. Suggested-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220118184448.852996-2-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12target/ppc: Add extra float instructions to POWER5P processorsCédric Le Goater
ISA v2.03 introduced Floating Round to Integer instructions : frin, friz, frip, and frim. Add them to POWER5+. The PPC_FLOAT_EXT flag also includes the fre (Floating Reciprocal Estimate) instruction which was introduced in ISA v2.0x. The architecture document says its optional and that might be the reason why it has been kept under the PPC_FLOAT_EXT flag. This means 970 CPUs can not use it under QEMU, which doesn't seem to be a problem. Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12target/ppc: Add popcntb instruction to POWER5+ processorsCédric Le Goater
popcntb instruction was added in ISA v2.02. Add support for POWER5+ processors since they implement ISA v2.03. PPC970 CPUs implement v2.01 and do not support popcntb. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Message-Id: <20220105095142.3990430-2-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-04target/ppc: Cache per-pmc insn and cycle count settingsRichard Henderson
This is the combination of frozen bit and counter type, on a per counter basis. So far this is only used by HFLAGS_INSN_CNT, but will be used more later. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> [danielhb: fixed PMC4 cyc_cnt shift, insn run latch code, MMCR0_FC handling, "PMC[1-6]" comment] Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220103224746.167831-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-04ppc/ppc405: Dump specific registersCédric Le Goater
Rework slightly ppc_cpu_dump_state() to replace the various 'if' statements with a 'switch'. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211222064025.1541490-9-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220103063441.3424853-10-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-04ppc/ppc405: Introduce a store helper for SPR_40x_PIDCédric Le Goater
The PID SPR of the 405 CPU contains the translation ID of the TLB which is a 8-bit field. Enforce the mask with a store helper. Cc: Christophe Leroy <christophe.leroy@c-s.fr> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211222064025.1541490-8-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220103063441.3424853-9-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-04ppc/ppc405: Restore TCR and STR write handlersCédric Le Goater
The 405 timers were broken when booke support was added. Assumption was made that the register numbers were the same but it's not : SPR_BOOKE_TSR (0x150) SPR_BOOKE_TCR (0x154) SPR_40x_TSR (0x3D8) SPR_40x_TCR (0x3DA) Cc: Christophe Leroy <christophe.leroy@c-s.fr> Fixes: ddd1055b07fd ("PPC: booke timers") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211222064025.1541490-5-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220103063441.3424853-6-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc/power8-pmu.c: add PM_RUN_INST_CMPL (0xFA) eventDaniel Henrique Barboza
PM_RUN_INST_CMPL, instructions completed with the run latch set, is the architected PowerISA v3.1 event defined with PMC4SEL = 0xFA. Implement it by checking for the CTRL RUN bit before incrementing the counter. To make this work properly we also need to force a new translation block each time SPR_CTRL is written. A small tweak in pmu_increment_insns() is then needed to only increment this event if the thread has the run latch. Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211201151734.654994-8-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: PMU: update counters on MMCR1 writeDaniel Henrique Barboza
MMCR1 determines the events to be sampled by the PMU. Updating the counters at every MMCR1 write ensures that we're not sampling more or less events by looking only at MMCR0 and the PMCs. It is worth noticing that both the Book3S PowerPC PMU, and this IBM Power8+ PMU that we're modeling, also uses MMCRA, MMCR2 and MMCR3 to control the PMU. These three registers aren't being handled in this initial implementation, so for now we're controlling all the PMU aspects using MMCR0, MMCR1 and the PMCs. Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211201151734.654994-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: PMU: update counters on PMCs r/wDaniel Henrique Barboza
Calling pmu_update_cycles() on every PMC read/write operation ensures that the values being fetched are up to date with the current PMU state. In theory we can get away by just trapping PMCs reads, but we're going to trap PMC writes to deal with counter overflow logic later on. Let's put the required wiring for that and make our lives a bit easier in the next patches. Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211201151734.654994-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: PMU basic cycle count for pseries TCGDaniel Henrique Barboza
This patch adds the barebones of the PMU logic by enabling cycle counting. The overall logic goes as follows: - MMCR0 reg initial value is set to 0x80000000 (MMCR0_FC set) to avoid having to spin the PMU right at system init; - to retrieve the events that are being profiled, pmc_get_event() will check the current MMCR0 and MMCR1 value and return the appropriate PMUEventType. For PMCs 1-4, event 0x2 is the implementation dependent value of PMU_EVENT_INSTRUCTIONS and event 0x1E is the implementation dependent value of PMU_EVENT_CYCLES. These events are supported by IBM Power chips since Power8, at least, and the Linux Perf driver makes use of these events until kernel v5.15. For PMC1, event 0xF0 is the architected PowerISA event for cycles. Event 0xFE is the architected PowerISA event for instructions; - if the counter is frozen, either via the global MMCR0_FC bit or its individual frozen counter bits, PMU_EVENT_INACTIVE is returned; - pmu_update_cycles() will go through each counter and update the values of all PMCs that are counting cycles. This function will be called every time a MMCR0 update is done to keep counters values up to date. Upcoming patches will use this function to allow the counters to be properly updated during read/write of the PMCs and MMCR1 writes. Given that the base CPU frequency is fixed at 1Ghz for both powernv and pseries clock, cycle calculation assumes that 1 nanosecond equals 1 CPU cycle. Cycle value is then calculated by adding the elapsed time, in nanoseconds, of the last cycle update done via pmu_update_cycles(). Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211201151734.654994-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: introduce PMUEventType and PMU overflow timersDaniel Henrique Barboza
This patch starts an IBM Power8+ compatible PMU implementation by adding the representation of PMU events that we are going to sample, PMUEventType. This enum represents a Perf event that is being sampled by a specific counter 'sprn'. Events that aren't available (i.e. no event was set in MMCR1) will be of type 'PMU_EVENT_INVALID'. Events that are inactive due to frozen counter bits state are of type 'PMU_EVENT_INACTIVE'. Other types added in this patch are PMU_EVENT_CYCLES and PMU_EVENT_INSTRUCTIONS. More types will be added later on. Let's also add the required PMU cycle overflow timers. They will be used to trigger cycle overflows when cycle events are being sampled. This timer will call cpu_ppc_pmu_timer_cb(), which in turn calls fire_PMC_interrupt(). Both functions are stubs that will be implemented later on when EBB support is added. Two new helper files are created to host this new logic. cpu_ppc_pmu_init() will init all overflow timers during CPU init time. Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211201151734.654994-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: Fix e6500 bootFabiano Rosas
When Altivec support was added to the e6500 kernel in 2012[1], the QEMU code was not changed, so we don't register the VPU/VPUA exceptions for the e6500: qemu: fatal: Raised an exception without defined vector 73 Note that the error message says 73, instead of 32, which is the IVOR for VPU. This is because QEMU knows only knows about the VPU interrupt for the 7400s. In theory, we should not be raising _that_ VPU interrupt, but instead another one specific for the e6500. We unfortunately cannot register e6500-specific VPU/VPUA interrupts because the SPEU/EFPDI interrupts also use IVOR32/33. These are present only in the e500v1/2 versions. From the user manual: e500v1, e500v2: only SPEU/EFPDI/EFPRI e500mc, e5500: no SPEU/EFPDI/EFPRI/VPU/VPUA e6500: only VPU/VPUA So I'm leaving IVOR32/33 as SPEU/EFPDI, but altering the dispatch code to convert the VPU #73 to a #32 when we're in the e6500. Since the handling for SPEU and VPU is the same this is the only change that's needed. The EFPDI is not implemented and will cause an abort. I don't think it worth it changing the error message to take VPUA into consideration, so I'm not changing anything there. This bug was discussed in the thread: https://lists.gnu.org/archive/html/qemu-ppc/2021-06/msg00222.html 1- https://git.kernel.org/torvalds/c/cd66cc2ee52 Reported-by: <mario@locati.it> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211213133542.2608540-1-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: remove 401/403 CPUsCédric Le Goater
They have been there since 2007 without any board using them, most were protected by a TODO define. Drop support. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211202191108.1291515-1-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: Set 601v exception model idFabiano Rosas
The exception model id for 601v has been removed without mention why. I assume it was inadvertent and restore it here. Fixes: b632a148b6 ("target-ppc: Use QOM method dispatch for MMU fault handling") Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211208123029.2052625-4-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: Remove 603e exception modelFabiano Rosas
The 603e uses the same exception code as 603 so we don't need a dedicated entry for it. This is only a removal of redundant code, no functional change. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211208123029.2052625-3-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: Fix MPCxxx FPU interrupt addressFabiano Rosas
The Floating-point Unavailable and Decrementer interrupts are being registered at the same 0x900 address. The FPU should be at 0x800 instead. Verified on MPC555, MPC860 and MPC885 user manuals. Reported-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211208123029.2052625-2-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: Remove the software TLB model of 7450 CPUsFabiano Rosas
(Applies to 7441, 7445, 7450, 7451, 7455, 7457, 7447, 7447a and 7448) The QEMU-side software TLB implementation for the 7450 family of CPUs is being removed due to lack of known users in the real world. The last users in the code were removed by the two previous commits. A brief history: The feature was added in QEMU by commit 7dbe11acd8 ("Handle all MMU models in switches...") with the mention that Linux was not able to handle the TLB miss interrupts and the MMU model would be kept disabled. At some point later, commit 8ca3f6c382 ("Allow selection of all defined PowerPC 74xx (aka G4) CPUs.") enabled the model for the 7450 family without further justification. We have since the year 2011 [1] been unable to run OpenBIOS in the 7450s and have not heard of any other software that is used with those CPUs in QEMU. Attempts were made to find a guest OS that implemented the TLB miss handlers and none were found among Linux 5.15, FreeBSD 13, MacOS9, MacOSX and MorphOS 3.15. All CPUs that registered this feature were moved to an MMU model that replaces the software TLB with a QEMU hardware TLB implementation. They can now run the same software as the 7400 CPUs, including the OSes mentioned above. References: - https://bugs.launchpad.net/qemu/+bug/812398 https://gitlab.com/qemu-project/qemu/-/issues/86 - https://lists.nongnu.org/archive/html/qemu-ppc/2021-11/msg00289.html message id: 20211119134431.406753-1-farosas@linux.ibm.com Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211130230123.781844-4-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: Disable unused facilities in the e600 CPUFabiano Rosas
The e600 CPU is a successor of the 7448 and like all the 7450s CPUs, it has an optional software TLB feature. We have determined that there is no OS software support for the 7450 software TLB available these days. See the previous commit for more information. This patch disables the SPRs and instructions related to software TLB from the e600 CPU. No functional change intended. These facilities should be used by the OS in interrupt handlers for interrupts that QEMU never generates. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211130230123.781844-3-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: Disable software TLB for the 7450 familyFabiano Rosas
(Applies to 7441, 7445, 7450, 7451, 7455, 7457, 7447 and 7447a)* We have since 2011 [1] been unable to run OpenBIOS in the 7450s and have not heard of any other software that is used with those CPUs in QEMU. A current discussion [2] shows that the 7450 software TLB is unsupported in Linux 5.15, FreeBSD 13, MacOS9, MacOSX and MorphOS 3.15. With no known support in firmware or OS, this means that no code for any of the 7450 CPUs is ever ran in QEMU. Since the implementation in QEMU of the 7400 MMU is the same as the 7450, except for the software TLB vs. hardware TLB search, this patch changes all 7450 cpus to the 7400 MMU model. This has the practical effect of disabling the software TLB feature while keeping other aspects of address translation working as expected. This allow us to run software on the 7450 family again. *- note that the 7448 is currently aliased in QEMU for a 7400, so it is unaffected by this change. 1- https://bugs.launchpad.net/qemu/+bug/812398 https://gitlab.com/qemu-project/qemu/-/issues/86 2- https://lists.nongnu.org/archive/html/qemu-ppc/2021-11/msg00289.html message id: 20211119134431.406753-1-farosas@linux.ibm.com Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211130230123.781844-2-farosas@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-11-03Merge remote-tracking branch ↵Richard Henderson
'remotes/vivier/tags/trivial-branch-for-6.2-pull-request' into staging Trivial patches branch pull request 20211101 v2 # gpg: Signature made Tue 02 Nov 2021 07:21:44 PM EDT # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] * remotes/vivier/tags/trivial-branch-for-6.2-pull-request: hw/input/lasips2: Fix typos in function names MAINTAINERS: Split HPPA TCG vs HPPA machines/hardware hw/core/machine: Add the missing delimiter in cpu_slot_to_string() monitor: Trim some trailing space from human-readable output Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-02target/ppc: Implement ppc_cpu_record_sigsegvRichard Henderson
Record DAR, DSISR, and exception_index. That last means that we must exit to cpu_loop ourselves, instead of letting exception_index being overwritten. This is exactly what the user-mode ppc_cpu_tlb_fill does, so simply rename it as ppc_cpu_record_sigsegv. Reviewed-by: Warner Losh <imp@bsdimp.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-10-31monitor: Trim some trailing space from human-readable outputMarkus Armbruster
I noticed -cpu help printing enough trailing spaces to make the output at least 84 characters wide. Looks ugly unless the terminal is wider. Ugly or not, trailing spaces are stupid. The culprit is this line in x86_cpu_list_entry(): qemu_printf("x86 %-20s %-58s\n", name, desc); This prints a string with minimum field left-justified right before a newline. Change it to qemu_printf("x86 %-20s %s\n", name, desc); which avoids the trailing spaces and is simpler to boot. A search for the pattern with "git-grep -E '%-[0-9]+s\\n'" found a few more instances. Change them similarly. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Max Filippov <jcmvbkbc@gmail.com> Message-Id: <20211009152401.2982862-1-armbru@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-21target/ppc: adding user read/write functions for PMCsDaniel Henrique Barboza
Problem state needs to be able to read and write the PMU counters, otherwise it won't be aware of any sampling result that the PMU produces after a Perf run. This patch does that in a similar fashion as already done in the previous patches. PMCs 5 and 6 have a special condition, aside from the constraints that are common with PMCs 1-4, where they are not part of the PMU if MMCR0_PMCC is 0b11. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211018010133.315842-5-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-10-21target/ppc: add user read/write functions for MMCR2Daniel Henrique Barboza
Similar to the previous patch, let's add problem state read/write access to the MMCR2 SPR, which is also a group A PMU SPR that needs to be filtered to be read/written by userspace. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211018010133.315842-4-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-10-21target/ppc: add user read/write functions for MMCR0Gustavo Romero
Userspace need access to PMU SPRs to be able to operate the PMU. One of such SPRs is MMCR0. MMCR0, as defined by PowerISA v3.1, is classified as a 'group A' PMU register. This class of registers has common read/write rules that are governed by MMCR0 PMCC bits. MMCR0 is also not fully exposed to problem state: only MMCR0_FC, MMCR0_PMAO and MMCR0_PMAE bits are readable/writable in this case. This patch exposes MMCR0 to userspace by doing the following: - two new callbacks, spr_read_MMCR0_ureg() and spr_write_MMCR0_ureg(), are added to be used as problem state read/write callbacks of UMMCR0. Both callbacks filters the amount of bits userspace is able to read/write by using a MMCR0_UREG_MASK; - problem state access control is done by the spr_groupA_read_allowed() and spr_groupA_write_allowed() helpers. These helpers will read the current PMCC bits from DisasContext and check whether the read/write MMCR0 operation is valid or noti; - to avoid putting exclusive PMU logic into the already loaded translate.c file, let's create a new 'power8-pmu-regs.c.inc' file that will hold all the spr_read/spr_write functions of PMU registers. The 'power8' name of this new file intends to hint about the proven support of the PMU logic to be added. The code has been tested with the IBM POWER chip family, POWER8 being the oldest version tested. This doesn't mean that the PMU logic will break with any other PPC64 chip that implements Book3s, but rather that we can't assert that it works properly with any Book3s compliant chip. CC: Gustavo Romero <gustavo.romero@linaro.org> Signed-off-by: Gustavo Romero <gromero@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211018010133.315842-3-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-14target/ppc: Restrict cpu_exec_interrupt() handler to sysemuPhilippe Mathieu-Daudé
Restrict cpu_exec_interrupt() and its callees to sysemu. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Warner Losh <imp@bsdimp.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20210911165434.531552-18-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-08-27ppc: Add a POWER10 DD2 CPUCédric Le Goater
The POWER10 DD2 CPU adds an extra LPCR[HAIL] bit. DD1 doesn't have HAIL but since it does not break the modeling and that we don't plan to support DD1, modify the LPCR mask of all the POWER10 family. Setting the HAIL bit is a requirement to support the scv instruction on PowerNV POWER10 platforms since glibc-2.33. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210809134547.689560-2-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-18 01:57:27 +0000