aboutsummaryrefslogtreecommitdiff
path: root/include/hw/ppc
AgeCommit message (Collapse)Author
2023-01-08include: Include headers where neededMarkus Armbruster
A number of headers neglect to include everything they need. They compile only if the headers they need are already included from elsewhere. Fix that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20221222120813.727830-3-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21hw/ppc/spapr: Reduce "vof.h" inclusionPhilippe Mathieu-Daudé
Currently objects including "hw/ppc/spapr.h" are forced to be target specific due to the inclusion of "vof.h" in "spapr.h". "spapr.h" only uses a Vof pointer, so doesn't require the structure declaration. The only place where Vof structure is accessed is in spapr.c, so include "vof.h" there, and forward declare the structure in "spapr.h". Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20221213123550.39302-4-philmd@linaro.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-12-21hw/ppc/vof: Do not include the full "cpu.h"Philippe Mathieu-Daudé
"vof.h" doesn't need the full "cpu.h" to get the target_ulong definition, including "exec/cpu-defs.h" is enough. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20221213123550.39302-3-philmd@linaro.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-12-16hw/pci-host/pnv_phb3_msi: Convert TYPE_PHB3_MSI to 3-phase resetPeter Maydell
Convert the TYPE_PHB3_MSI class to 3-phase reset, so we can avoid using the device_class_set_parent_reset() function. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20221125115240.3005559-8-peter.maydell@linaro.org
2022-10-28ppc4xx_sdram: Move ppc4xx_sdram_banks() to ppc4xx_sdram.cBALATON Zoltan
This function is only used by the ppc4xx memory controller models so it can be made static. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <b1504a82157a586aa284e8ee3b427b9a07b24169.1666194485.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc440_uc.c: Move some macros to ppc4xx.hBALATON Zoltan
These are used by both the SDRAM controller model and system DCRs. In preparation to move SDRAM controller in its own file move these macros to the ppc4xx.h header. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <74d9bf4891e2ccceb52bb6ca6b54fd3f37a9fb04.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc440_sdram: QOM'ifyBALATON Zoltan
Change the ppc440_sdram model to a QOM class derived from the PPC4xx-dcr-device and name it ppc4xx-sdram-ddr2. This is mostly modelling the DDR2 SDRAM controller found in the 460EX (used on the sam460ex board). Newer SoCs (regardless of their PPC core, e.g. 405EX) may have this controller but we only emulate enough of it for the sam460ex u-boot firmware. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <3e82ae575c7c41e464a0082d55ecb4ebcc4d4329.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx_sdram: Rename functions to prevent name clashesBALATON Zoltan
Rename functions to avoid name clashes when moving the DDR2 controller model currently called ppc440_sdram to ppc4xx_devs. This also more clearly shows which function belongs to which model. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <9c09d10fbf36940ebbe30d7038d69cf3f2e58371.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc440_sdram: Get rid of the init RAM hackBALATON Zoltan
Remove the do_init parameter of ppc440_sdram_init and enable SDRAM controller from the board. Firmware does this so it may only be needed when booting with -kernel without firmware but we enable SDRAM unconditionally to preserve previous behaviour. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <c2eda8f83c82f655aa7821a5a8c9310484bd6a1d.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx_sdram: QOM'ifyBALATON Zoltan
Change the ppc4xx_sdram model to a QOM class derived from the PPC4xx-dcr-device and name it ppc4xx-sdram-ddr. This is mostly modelling the DDR SDRAM controller found in the 440EP (used on the bamboo board) but also backward compatible with the older DDR controllers on some 405 SoCs so we also use it for those now. This likely does not cause problems for guests we run as the new features are just not accessed but to model 405 SoC accurately some features may have to be disabled or the model split between 440 and older. Newer SoCs (regardless of their PPC core, e.g. 405EX) may have an updated DDR2 SDRAM controller implemented by the ppc440_sdram model (only partially, enough for the 460EX on the sam460ex) that is not yet QOM'ified in this patch. That is intended to become ppc4xx-sdram-ddr2 when QOM'ified later. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <8f820487fc9011343032c422ecdf3e8ee74d8c11.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx_sdram: Move size check to ppc4xx_sdram_init()BALATON Zoltan
Instead of checking if memory size is valid in board code move this check to ppc4xx_sdram_init() as this is a restriction imposed by the SDRAM controller. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <39e5129dd095b285676a6267c5753786da1bc30d.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx: Use Ppc4xxSdramBank in ppc4xx_sdram_banks()BALATON Zoltan
Change ppc4xx_sdram_banks() to take one Ppc4xxSdramBank array instead of the separate arrays and adjust ppc4xx_sdram_init() and ppc440_sdram_init() accordingly as well as machines using these. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <e3a1fea51f29779fd6a61be90a29c684f3299544.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx_sdram: Get rid of the init RAM hackBALATON Zoltan
The do_init parameter of ppc4xx_sdram_init() is used to map memory regions that is normally done by the firmware by programming the SDRAM controller. Do this from board code emulating what firmware would do when booting a kernel directly from -kernel without a firmware so we can get rid of this do_init hack. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <d6c44c870befa1a075e21f1a59926dcdaff63f6b.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx: Introduce Ppc4xxSdramBank structBALATON Zoltan
Instead of storing sdram bank parameters in unrelated arrays put them in a struct so it's clear they belong to the same bank and simplify the state struct using this bank type. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <5eb82d0424c584b2b9e6f7bc51560f8189ed21bb.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-09-20hw/ppc/spapr: Fix code style problems reported by checkpatchBernhard Beschow
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20220919231720.163121-5-shentey@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc4xx: Rename ppc405-ebc to ppc4xx-ebcBALATON Zoltan
This device is shared between different 4xx socs. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <63d9b14c8ff5f73e35bffca1036394b5235735ee.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc4xx: Move EBC model to ppc4xx_devs.cBALATON Zoltan
The EBC is shared between 405 and 440 so move it to shared file. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <10eae70509ca4bd74858fc2c0a0f0e4eb9330199.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc4xx: Rename ppc405-plb to ppc4xx-plbBALATON Zoltan
This device is shared between different 4xx socs. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <5b13ebfd12a71a28035bed5a915cbeee81cf21d1.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc4xx: Move PLB model to ppc4xx_devs.cBALATON Zoltan
The PLB is shared between 405 and 440 so move it to the shared file. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <2498384bf3e18959ee8cb984d72fb66b8a6ecadc.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/ppc405: QOM'ify MALCédric Le Goater
The Memory Access Layer (MAL) controller is currently modeled as a DCR device with 4 IRQs. Also drop the ppc4xx_mal_init() helper and adapt the sam460ex machine. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> [balaton: ppc4xx_dcr_register changes, add finalize method] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <d54a243dff94d95ba30dbcc09c27700a90ade932.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/ppc4xx: Introduce a DCR device modelCédric Le Goater
The Device Control Registers (DCR) of on-SoC devices are accessed by software through the use of the mtdcr and mfdcr instructions. These are converted in transactions on a side band bus, the DCR bus, which connects the on-SoC devices to the CPU. Ideally, we should model these accesses with a DCR namespace and DCR memory regions but today the DCR handlers are installed in a DCR table under the CPU. Instead, introduce a little device model wrapper to hold a CPU link and handle registration of DCR handlers. The DCR device inherits from SysBus because most of these devices also have MMIO regions and/or IRQs. Being a SysBusDevice makes things easier to install the device model in the overall SoC. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> [balaton: Explicit opaque parameter for dcr callbacks] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <9b21bdf55e0a728f093bad299e030d98f302ded0.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/ppc405: QOM'ify CPUCédric Le Goater
Drop the use of ppc4xx_init() and duplicate a bit of code related to clocks in the SoC realize routine. We will clean that up in the following patches. ppc_dcr_init() simply allocates default DCR handlers for the CPU. Maybe this could be done in model initializer of the CPU families needing it. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20220809153904.485018-8-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/pnv: turn chip8->phbs[] into a PnvPHB* arrayDaniel Henrique Barboza
When enabling user created PHBs (a change reverted by commit 9c10d86fee) we were handling PHBs created by default versus by the user in different manners. The only difference between these PHBs is that one will have a valid phb3->chip that is assigned during pnv_chip_power8_realize(), while the user created needs to search which chip it belongs to. Aside from that there shouldn't be any difference. Making the default PHBs behave in line with the user created ones will make it easier to re-introduce them later on. It will also make the code easier to follow since we are dealing with them in equal manner. The first step is to turn chip8->phbs[] into a PnvPHB3 pointer array. This will allow us to assign user created PHBs into it later on. The way we initilize the default case is now more in line with that would happen with the user created case: the object is created, parented by the chip because pnv_xscom_dt() relies on it, and then assigned to the array. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-6-danielhb413@gmail.com>
2022-08-31ppc/pnv: add helpers for pnv-phb user devicesDaniel Henrique Barboza
pnv_parent_qom_fixup() and pnv_parent_bus_fixup() are versions of the helpers that were reverted by commit 9c10d86fee "ppc/pnv: Remove user-created PHB{3,4,5} devices". They are needed to amend the QOM and bus hierarchies of user created pnv-phbs, matching them with default pnv-phbs. A new helper pnv_phb_user_device_init() is created to handle user-created devices setup. We're going to call it inside pnv_phb_realize() in case we're realizing an user created device. This will centralize all user device realated in a single spot, leaving the realize functions of the phb3/phb4 backends untouched. Another helper called pnv_chip_add_phb() was added to handle the particularities of each chip version when adding a new PHB. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-5-danielhb413@gmail.com>
2022-08-31ppc/pnv: move attach_root_port helper to pnv-phb.cDaniel Henrique Barboza
The helper is only used in this file. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-13-danielhb413@gmail.com>
2022-08-31ppc/pnv: remove root port name from pnv_phb_attach_root_port()Daniel Henrique Barboza
We support only a single root port, PNV_PHB_ROOT_PORT. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-10-danielhb413@gmail.com>
2022-08-31ppc/pnv: turn PnvPHB3 into a PnvPHB backendDaniel Henrique Barboza
We need a handful of changes that needs to be done in a single swoop to turn PnvPHB3 into a PnvPHB backend. In the PnvPHB3, since the PnvPHB device implements PCIExpressHost and will hold the PCI bus, change PnvPHB3 parent to TYPE_DEVICE. There are a couple of instances in pnv_phb3.c that needs to access the PCI bus, so a phb_base pointer is added to allow access to the parent PnvPHB. The PnvPHB3 root port will now be connected to a PnvPHB object. In pnv.c, the powernv8 machine chip8 will now hold an array of PnvPHB objects. pnv_get_phb3_child() needs to be adapted to return the PnvPHB3 backend from the PnvPHB child. A global property is added in pnv_machine_power8_class_init() to ensure that all PnvPHBs are created with phb->version = 3. After all these changes we're still able to boot a powernv8 machine with default settings. The real gain will come with user created PnvPHB devices, coming up next. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-4-danielhb413@gmail.com>
2022-08-31ppc/pnv: Add initial P9/10 SBE modelNicholas Piggin
The SBE (Self Boot Engine) are on-chip microcontrollers that perform early boot steps, as well as provide some runtime facilities (e.g., timer, secure register access, MPIPL). The latter facilities are accessed mostly via a message system called SBEFIFO. This driver provides initial emulation for the SBE runtime registers and a very basic SBEFIFO implementation that provides the timer command. This covers the basic SBE behaviour expected by skiboot when booting. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20220811093726.1442343-1-npiggin@gmail.com> [danielhb: fixed SBE_HOST_RESPONSE_MASK long line] Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-07-06ppc/spapr: Implement H_WATCHDOGAlexey Kardashevskiy
The new PAPR 2.12 defines a watchdog facility managed via the new H_WATCHDOG hypercall. This adds H_WATCHDOG support which a proposed driver for pseries uses: https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=303120 This was tested by running QEMU with a debug kernel and command line: -append \ "pseries-wdt.timeout=60 pseries-wdt.nowayout=1 pseries-wdt.action=2" and running "echo V > /dev/watchdog0" inside the VM. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220622051008.1067464-1-aik@ozlabs.ru> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-07-06spapr/ddw: Reset DMA when the last non-default window is removedAlexey Kardashevskiy
PAPR+/LoPAPR says: === The platform must restore the default DMA window for the PE on a call to the ibm,remove-pe-dma-window RTAS call when all of the following are true: a. The call removes the last DMA window remaining for the PE. b. The DMA window being removed is not the default window === This resets DMA as PAPR mandates. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220622052955.1069903-1-aik@ozlabs.ru> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-07-06ppc/pnv: assign pnv-phb-root-port chassis/slot earlierDaniel Henrique Barboza
It is not advisable to execute an object_dynamic_cast() to poke into bus->qbus.parent and follow it up with a C cast into the PnvPHB type we think we got. In fact this is not needed. There is nothing sophisticated being done with the PHB object retrieved during root_port_realize() for both PHB3 and PHB4. We're retrieving a PHB reference just to access phb->chip_id and phb->phb_id and use them to define the chassis/slot of the root port. phb->phb_id is already being passed to pnv_phb_attach_root_port() via the 'index' parameter. Let's also add a 'chip_id' parameter to this function and assign chassis and slot right there. This will spare us from the hassle of accessing the PHB object inside realize(). Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220621173436.165912-4-danielhb413@gmail.com>
2022-07-06ppc/pnv: attach phb3/phb4 root ports in QOM treeDaniel Henrique Barboza
At this moment we leave the pnv-phb3(4)-root-port unattached in QOM: /unattached (container) (...) /device[2] (pnv-phb3-root-port) /bus master container[0] (memory-region) /bus master[0] (memory-region) /pci_bridge_io[0] (memory-region) /pci_bridge_io[1] (memory-region) /pci_bridge_mem[0] (memory-region) /pci_bridge_pci[0] (memory-region) /pci_bridge_pref_mem[0] (memory-region) /pci_bridge_vga_io_hi[0] (memory-region) /pci_bridge_vga_io_lo[0] (memory-region) /pci_bridge_vga_mem[0] (memory-region) /pcie.0 (PCIE) Let's make changes in pnv_phb_attach_root_port() to attach the created root ports to its corresponding PHB. This is the result afterwards: /pnv-phb3[0] (pnv-phb3) /lsi (ics) /msi (phb3-msi) /msi32[0] (memory-region) /msi64[0] (memory-region) /pbcq (pnv-pbcq) (...) /phb3_iommu[0] (pnv-phb3-iommu-memory-region) /pnv-phb3-root.0 (pnv-phb3-root) /pnv-phb3-root-port[0] (pnv-phb3-root-port) /bus master container[0] (memory-region) /bus master[0] (memory-region) /pci_bridge_io[0] (memory-region) /pci_bridge_io[1] (memory-region) /pci_bridge_mem[0] (memory-region) /pci_bridge_pci[0] (memory-region) /pci_bridge_pref_mem[0] (memory-region) /pci_bridge_vga_io_hi[0] (memory-region) /pci_bridge_vga_io_lo[0] (memory-region) /pci_bridge_vga_mem[0] (memory-region) /pcie.0 (PCIE) Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220621173436.165912-3-danielhb413@gmail.com>
2022-05-26pseries: allow setting stdout-path even on machines with a VGAPaolo Bonzini
-machine graphics=off is the usual way to tell the firmware or the OS that the user wants a serial console. The pseries machine however does not support this, and never adds the stdout-path node to the device tree if a VGA device is provided. This is in addition to the other magic behavior of VGA devices, which is to add a keyboard and mouse to the default USB bus. Split spapr->has_graphics in two variables so that the two behaviors can be separated: the USB devices remains the same, but the stdout-path is added even with "-device VGA -machine graphics=off". Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220507054826.124936-1-pbonzini@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-05-11Clean up ill-advised or unusual header guardsMarkus Armbruster
Leading underscores are ill-advised because such identifiers are reserved. Trailing underscores are merely ugly. Strip both. Our header guards commonly end in _H. Normalize the exceptions. Macros should be ALL_CAPS. Normalize the exception. Done with scripts/clean-header-guards.pl. include/hw/xen/interface/ and tools/virtiofsd/ left alone, because these were imported from Xen and libfuse respectively. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220506134911.2856099-3-armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2022-05-05ppc/xive: Update the state of the External interrupt signalFrederic Barrat
When pulling or pushing an OS context from/to a CPU, we should re-evaluate the state of the External interrupt signal. Otherwise, we can end up catching the External interrupt exception in hypervisor mode, which is unexpected. The problem is best illustrated with the following scenario: 1. an External interrupt is raised while the guest is on the CPU. 2. before the guest can ack the External interrupt, an hypervisor interrupt is raised, for example the Hypervisor Decrementer or Hypervisor Virtualization interrupt. The hypervisor interrupt forces the guest to exit while the External interrupt is still pending. 3. the hypervisor handles the hypervisor interrupt. At this point, the External interrupt is still pending. So it's very likely to be delivered while the hypervisor is running. That's unexpected and can result in an infinite loop where the hypervisor catches the External interrupt, looks for an interrupt in its hypervisor queue, doesn't find any, exits the interrupt handler with the External interrupt still raised, repeat... The fix is simply to always lower the External interrupt signal when pulling an OS context. It means it needs to be raised again when re-pushing the OS context. Fortunately, it's already the case, as we now always call xive_tctx_ipb_update(), which will raise the signal if needed. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220429071620.177142-3-fbarrat@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-04-20hw/ppc: change indentation to spaces from TABsGuo Zhi
There are still some files in the QEMU PPC code base that use TABs for indentation instead of using spaces. The TABs should be replaced so that we have a consistent coding style. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/374 Signed-off-by: Guo Zhi <qtxuning1999@sjtu.edu.cn> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220412021240.2080218-1-qtxuning1999@sjtu.edu.cn> [danielhb: trimmed commit msg to 72 chars per line] Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-04-20ppc/pnv: Remove PnvPsiClas::irq_setCédric Le Goater
All devices raising PSI interrupts are now converted to use GPIO lines and the pnv_psi_irq_set() routines have become useless. Drop them. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220323072846.1780212-5-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-04-20ppc/pnv: Remove PnvOCC::psi linkCédric Le Goater
Use an anonymous output GPIO line to connect the OCC device with the PSIHB device and raise the appropriate PSI IRQ line depending on the processor model. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220323072846.1780212-4-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-04-20ppc/pnv: Remove PnvLpcController::psi linkCédric Le Goater
Create an anonymous output GPIO line to connect the LPC device with the PSIHB device and raise the appropriate PSI IRQ line depending on the processor model. A temporary __pnv_psi_irq_set() routine is introduced to handle the transition. It will be removed when all devices raising PSI interrupts are converted to use GPIOs. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220323072846.1780212-3-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-04-20ppc/pnv: Fix PSI IRQ definitionCédric Le Goater
On HW, the PSI and FSP interrupt levels are muxed under the same interrupt number. For coding reasons, an extra IRQ number was introduced to index register values in an array. It increased the count of IRQs which do not fit in the PSI IRQ range anymore. The PSI and FSP interrupts should be modeled with an extra level of GPIO lines but since QEMU does not support them, simply drop the extra number to stay within the IRQ range. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220323072846.1780212-2-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-04-20ppc/spapr/ddw: Add 2M pagesizeAlexey Kardashevskiy
Recently the LoPAPR spec got a new 2MB pagesize to support in Dynamic DMA Windows API (DDW), this adds the new flag. Linux supports it since https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=38727311871 Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20220321071945.918669-1-aik@ozlabs.ru> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-04-04hw/ppc: free env->tb_env in spapr_unrealize_vcpu()Daniel Henrique Barboza
The timebase is allocated during spapr_realize_vcpu() and it's not freed. This results in memory leaks when doing vcpu unplugs: ==636935== ==636935== 144 (96 direct, 48 indirect) bytes in 1 blocks are definitely lost in loss record 6 ,461 of 8,135 ==636935== at 0x4897468: calloc (vg_replace_malloc.c:760) ==636935== by 0x5077213: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6400.4) ==636935== by 0x507757F: g_malloc0_n (in /usr/lib64/libglib-2.0.so.0.6400.4) ==636935== by 0x93C3FB: cpu_ppc_tb_init (ppc.c:1066) ==636935== by 0x97BC2B: spapr_realize_vcpu (spapr_cpu_core.c:268) ==636935== by 0x97C01F: spapr_cpu_core_realize (spapr_cpu_core.c:337) ==636935== by 0xD4626F: device_set_realized (qdev.c:531) ==636935== by 0xD55273: property_set_bool (object.c:2273) ==636935== by 0xD523DF: object_property_set (object.c:1408) ==636935== by 0xD588B7: object_property_set_qobject (qom-qobject.c:28) ==636935== by 0xD52897: object_property_set_bool (object.c:1477) ==636935== by 0xD4579B: qdev_realize (qdev.c:333) ==636935== This patch adds a cpu_ppc_tb_free() helper in hw/ppc/ppc.c to allow us to free the timebase. This leak is then solved by calling cpu_ppc_tb_free() in spapr_unrealize_vcpu(). Fixes: 6f4b5c3ec590 ("spapr: CPU hot unplug support") Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20220329124545.529145-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-14ppc/pnv: Remove user-created PHB{3,4,5} devicesCédric Le Goater
On a real system with POWER{8,9,10} processors, PHBs are sub-units of the processor, they can be deactivated by firmware but not plugged in or out like a PCI adapter on a slot. Nevertheless, having user-created PHBs in QEMU seemed to be a good idea for testing purposes : 1. having a limited set of PHBs speedups boot time. 2. it is useful to be able to mimic a partially broken topology you some time have to deal with during bring-up. PowerNV is also used for distro install tests and having libvirt support eases these tasks. libvirt prefers to run the machine with -nodefaults to be sure not to drag unexpected devices which would need to be defined in the domain file without being specified on the QEMU command line. For this reason : 3. -nodefaults should not include default PHBs User-created PHB{3,4,5} devices satisfied all these needs but reality proves to be a bit more complex, internally when modeling such devices, and externally when dealing with the user interface. Req 1. and 2. can be simply addressed differently with a machine option: "phb-mask=<uint>", which QEMU would use to enable/disable PHB device nodes when creating the device tree. For Req 3., we need to make sure we are taking the right approach. It seems that we should expose a new type of user-created PHB device, a generic virtualized one, that libvirt would use and not one depending on the processor revision. This needs more thinking. For now, remove user-created PHB{3,4,5} devices. All the cleanups we did are not lost and they will be useful for the next steps. Fixes: 5bc67b052b51 ("ppc/pnv: Introduce user creatable pnv-phb4 devices") Fixes: 1f6a88fffc75 ("ppc/pnv: Introduce support for user created PHB3 devices") Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220314130514.529931-1-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-02pnv/xive2: Add support for 8bits thread idCédric Le Goater
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-02pnv/xive2: Add support for automatic save&restoreCédric Le Goater
The XIVE interrupt controller on P10 can automatically save and restore the state of the interrupt registers under the internal NVP structure representing the VCPU. This saves a costly store/load in guest entries and exits. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-02xive2: Add a get_config() handler for the router configurationCédric Le Goater
Add GEN1 config even if we don't use it yet in the core framework. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-02ppc/pnv: add XIVE Gen2 TIMA supportCédric Le Goater
Only the CAM line updates done by the hypervisor are specific to POWER10. Instead of duplicating the TM ops table, we handle these commands locally under the PowerNV XIVE2 model. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-02ppc/pnv: Add support for PQ offload on PHB5Cédric Le Goater
The PQ_disable configuration bit disables the check done on the PQ state bits when processing new MSI interrupts. When bit 9 is enabled, the PHB forwards any MSI trigger to the XIVE interrupt controller without checking the PQ state bits. The XIVE IC knows from the trigger message that the PQ bits have not been checked and performs the check locally. This configuration bit only applies to MSIs and LSIs are still checked on the PHB to handle the assertion level. PQ_disable enablement is a requirement for StoreEOI. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-02ppc/xive: Add support for PQ state bits offloadCédric Le Goater
The trigger message coming from a HW source contains a special bit informing the XIVE interrupt controller that the PQ bits have been checked at the source or not. Depending on the value, the IC can perform the check and the state transition locally using its own PQ state bits. The following changes add new accessors to the XiveRouter required to query and update the PQ state bits. This only applies to the PowerNV machine. sPAPR accessors are provided but the pSeries machine should not be concerned by such complex configuration for the moment. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-02ppc/xive2: Add support for notification injection on ESB pagesCédric Le Goater
This is an internal offset used to inject triggers when the PQ state bits are not controlled locally. Such as for LSIs when the PHB5 are using the Address-Based Interrupt Trigger mode and on the END. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-12 09:07:12 +0000