summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
| * | ppc/ppc405: QOM'ify EBCCédric Le Goater2022-08-313-32/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EBC is currently modeled as a DCR device. Also drop the ppc405_ebc_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] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <51a0769ab605c5158f4f2f1c896725d5fe7a073b.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/ppc405: QOM'ify DMACédric Le Goater2022-08-312-79/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DMA controller is currently modeled as a DCR device with a couple of IRQs. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> [balaton: ppc4xx_dcr_register changes] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <4738b3c7cf18c328f05aaaddc555a46219431335.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/ppc405: QOM'ify GPIOCédric Le Goater2022-08-313-27/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GPIO controller is currently modeled as a simple SysBus device with a unique memory region. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> [balaton: Simplify sysbus device casts for readability] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <e95d7849f3768e1f9a2846c4b282392750678b3e.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/ppc405: QOM'ify OCMCédric Le Goater2022-08-312-38/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OCM controller is currently modeled as a simple DCR device with a couple of memory regions. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> [balaton: ppc4xx_dcr_register changes] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <ecb93d2d5993bb7a970365744c7d342d4abcb017.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/ppc405: QOM'ify GPTCédric Le Goater2022-08-313-47/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GPT controller is currently modeled as a SysBus device with a unique memory region, a couple of IRQs and a timer. 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: <8950ab26e78173f94ba65bc61bcfd0631de1fe61.1660746880.git.balaton@eik.bme.hu> [danielhb: check if timer != NULL in ppc405_gpt_finalize()] Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/ppc405: QOM'ify CPCCédric Le Goater2022-08-312-81/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CPC controller is currently modeled as a DCR device. Now that all clock settings are handled at the CPC level, change the SoC "sys-clk" property to be an alias on the same property in the CPC model. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> [balaton: ppc4xx_dcr_register changes] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <23393cb91a2c6c560a4461b3e9d1baa48ae28f74.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/ppc4xx: Introduce a DCR device modelCédric Le Goater2022-08-312-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ppc/ppc405: QOM'ify CPUCédric Le Goater2022-08-315-49/+32Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ppc/ppc405: Start QOMification of the SoCCédric Le Goater2022-08-313-77/+71Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This moves all the code previously done in the ppc405ep_init() routine under ppc405_soc_realize(). We can also adjust the number of banks now that we have control on ppc4xx_sdram_init(). Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20220809153904.485018-7-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/ppc405: Introduce a PPC405 SoCCédric Le Goater2022-08-313-11/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is an initial model to start QOMification of the PPC405 board. QOM'ified devices will be reintroduced one by one. Start with the memory regions, which name prefix is changed to "ppc405". Also, initialize only one RAM bank. The second bank is a dummy one (zero size) which is here to match the hard coded number of banks in ppc405ep_init(). 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-6-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/ppc405: Move SRAM under the ref405ep machineCédric Le Goater2022-08-311-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It doesn't belong to the generic machine nor the SoC. Fix a typo in the name while we are at it. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20220809153904.485018-5-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/ppc405: Move devices under the ref405ep machineCédric Le Goater2022-08-311-12/+19
| | | | | | | | | | | | | | | | | | | | | | | | Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220809153904.485018-4-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/ppc405: Introduce a PPC405 generic machineCédric Le Goater2022-08-311-3/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We will use this machine as a base to define the ref405ep and possibly the PPC405 hotfoot board as found in the Linux kernel. Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220809153904.485018-3-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/ppc405: Remove taihu machineCédric Le Goater2022-08-315-243/+7Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | It has been deprecated since 7.0. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220809153904.485018-2-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/pnv: fix QOM parenting of user creatable root portsDaniel Henrique Barboza2022-08-311-27/+20Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | User creatable root ports are being parented by the 'peripheral' or the 'peripheral-anon' container. This happens because this is the regular QOM schema for sysbus devices that are added via the command line. Let's make this QOM hierarchy similar to what we have with default root ports, i.e. the root port must be parented by the pnv-root-bus. To do that we change the qom and bus parent of the root port during root_port_realize(). The realize() is shared by the default root port code path, so we can remove the code inside pnv_phb_attach_root_port() that was adding the root port as a child of the bus as well. After all that, remove pnv_phb_attach_root_port() and create the root port explictly in the 'default_enabled()' case of pnv_phb_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: <20220819094748.400578-3-danielhb413@gmail.com>
| * | ppc/pnv: consolidate pnv_parent_*_fixup() helpersDaniel Henrique Barboza2022-08-311-15/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have 2 helpers that amends the QOM and parent bus of a given object, repectively. These 2 helpers are called together, and not by accident. Due to QOM internals, doing an object_unparent() will result in the device being removed from its parent bus. This means that changing the QOM parent requires reassigning the parent bus again. Create a single helper called pnv_parent_fixup(), documenting some of the QOM specifics that we're dealing with the unparenting/parenting mechanics, and handle both the QOM and the parent bus assignment. Next patch will make use of this function to handle a case where we need to change the QOM parent while keeping the same parent bus assigned beforehand. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220819094748.400578-2-danielhb413@gmail.com>
| * | ppc/pnv: user creatable pnv-phb for powernv10Daniel Henrique Barboza2022-08-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given that powernv9 and powernv10 uses the same pnv-phb backend, the logic to allow user created pnv-phbs for powernv10 is already in place. Let's flip the switch. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-11-danielhb413@gmail.com>
| * | ppc/pnv: change pnv_phb4_get_pec() to also retrieve chip10->pecsDaniel Henrique Barboza2022-08-311-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function assumes that we're always dealing with a PNV9_CHIP() object. This is not the case when the pnv-phb device belongs to a powernv10 machine. Change pnv_phb4_get_pec() to be able to work with PNV10_CHIP() if necessary. 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-10-danielhb413@gmail.com>
| * | ppc/pnv: enable user created pnv-phb for powernv9Daniel Henrique Barboza2022-08-313-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable pnv-phb user created devices for powernv9 now that we have everything in place. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-9-danielhb413@gmail.com>
| * | ppc/pnv: add PHB4 helpers for user created pnv-phbDaniel Henrique Barboza2022-08-311-3/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PHB4 backend relies on a link with the corresponding PEC element. This is trivial to do during machine_init() time for default devices, but not so much for user created ones. pnv_phb4_get_pec() is a small variation of the function that was reverted by commit 9c10d86fee "ppc/pnv: Remove user-created PHB{3,4,5} devices". We'll use it to determine the appropriate PEC for a given user created pnv-phb that uses a PHB4 backend. This is done during realize() time, in pnv_phb_user_device_init(). 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-8-danielhb413@gmail.com>
| * | ppc/pnv: enable user created pnv-phb for powernv8Daniel Henrique Barboza2022-08-312-16/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bulk of the work was already done by previous patches. Use defaults_enabled() to determine whether we need to create the default devices or not. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-7-danielhb413@gmail.com>
| * | ppc/pnv: turn chip8->phbs[] into a PnvPHB* arrayDaniel Henrique Barboza2022-08-312-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ppc/pnv: add helpers for pnv-phb user devicesDaniel Henrique Barboza2022-08-313-0/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ppc/pnv: set root port chassis and slot using Bus propertiesDaniel Henrique Barboza2022-08-311-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For default root ports we have a way of accessing chassis and slot, before root_port_realize(), via pnv_phb_attach_root_port(). For the future user created root ports this won't be the case: we can't use this helper because we don't have access to the PHB phb-id/chip-id values. In earlier patches we've added phb-id and chip-id to pnv-phb-root-bus objects. We're now able to use the bus to retrieve them. The bus is reachable for both user created and default devices, so we're changing all the code paths. This also allow us to validate these changes with the existing default devices. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-4-danielhb413@gmail.com>
| * | ppc/pnv: add phb-id/chip-id PnvPHB4RootBus propertiesDaniel Henrique Barboza2022-08-312-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The same rationale provided in the PHB3 bus case applies here. Note: we could have merged both buses in a single object, like we did with the root ports, and spare some boilerplate. The reason we opted to preserve both buses objects is twofold: - there's not user side advantage in doing so. Unifying the root ports presents a clear user QOL change when we enable user created devices back. The buses objects, aside from having a different QOM name, is transparent to the user; - we leave a door opened in case we want to increase the root port limit for phb4/5 later on without having to deal with phb3 code. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-3-danielhb413@gmail.com>
| * | ppc/pnv: add phb-id/chip-id PnvPHB3RootBus propertiesDaniel Henrique Barboza2022-08-312-1/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We rely on the phb-id and chip-id, which are PHB properties, to assign chassis and slot to the root port. For default devices this is no big deal: the root port is being created under pnv_phb_realize() and the values are being passed on via the 'index' and 'chip-id' of the pnv_phb_attach_root_port() helper. If we want to implement user created root ports we have a problem. The user created root port will not be aware of which PHB it belongs to, unless we're willing to violate QOM best practices and access the PHB via dev->parent_bus->parent. What we can do is to access the root bus parent bus. Since we're already assigning the root port as QOM child of the bus, and the bus is initiated using PHB properties, let's add phb-id and chip-id as properties of the bus. This will allow us trivial access to them, for both user-created and default root ports, without doing anything too shady with QOM. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-2-danielhb413@gmail.com>
| * | ppc/pnv: move attach_root_port helper to pnv-phb.cDaniel Henrique Barboza2022-08-313-26/+24Star
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ppc/pnv: remove PnvPHB4.versionDaniel Henrique Barboza2022-08-311-2/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | It's unused. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-12-danielhb413@gmail.com>
| * | ppc/pnv: remove pecc->rp_modelDaniel Henrique Barboza2022-08-312-3/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | The attribute is unused. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-11-danielhb413@gmail.com>
| * | ppc/pnv: remove root port name from pnv_phb_attach_root_port()Daniel Henrique Barboza2022-08-313-12/+7Star
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ppc/pnv: remove pnv-phb4-root-portDaniel Henrique Barboza2022-08-315-98/+6Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The unified pnv-phb-root-port can be used instead. The phb4-root-port device isn't exposed to the user in any official QEMU release so there's no ABI breakage in removing it. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-9-danielhb413@gmail.com>
| * | ppc/pnv: remove pnv-phb3-root-portDaniel Henrique Barboza2022-08-314-49/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The unified pnv-phb-root-port can be used in its place. There is no ABI breakage in doing so because no official QEMU release introduced user creatable pnv-phb3-root-port devices. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-8-danielhb413@gmail.com>
| * | ppc/pnv: add pnv-phb-root-port deviceDaniel Henrique Barboza2022-08-312-8/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have two very similar root-port devices, pnv-phb3-root-port and pnv-phb4-root-port. Both consist of a wrapper around the PCIESlot device that, until now, has no additional attributes. The main difference between the PHB3 and PHB4 root ports is that pnv-phb4-root-port has the pnv_phb4_root_port_reset() callback. All other differences can be merged in a single device without too much trouble. This patch introduces the unified pnv-phb-root-port that, in time, will be used as the default root port for the pnv-phb device. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-7-danielhb413@gmail.com>
| * | ppc/pnv: turn PnvPHB4 into a PnvPHB backendDaniel Henrique Barboza2022-08-314-31/+27Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the parent type of the PnvPHB4 device to TYPE_PARENT since the PCI bus is going to be initialized by the PnvPHB parent. Functions that needs to access the bus via a PnvPHB4 object can do so via the phb4->phb_base pointer. pnv_phb4_pec now creates a PnvPHB object. The powernv9 machine class will create PnvPHB devices with version '4'. powernv10 will create using version '5'. Both are using global machine properties in their class_init() to do that. These changes will benefit us when adding PnvPHB user creatable devices for powernv9 and powernv10. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-6-danielhb413@gmail.com>
| * | ppc/pnv: add PHB4 bus init helperDaniel Henrique Barboza2022-08-313-16/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to what we already did for the PnvPHB3 device, let's add a helper to init the bus when using a PnvPHB4. This helper will be used by PnvPHb when PnvPHB4 turns into a backend. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-5-danielhb413@gmail.com>
| * | ppc/pnv: turn PnvPHB3 into a PnvPHB backendDaniel Henrique Barboza2022-08-314-30/+26Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ppc/pnv: add PnvPHB base/proxy deviceDaniel Henrique Barboza2022-08-313-1/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PnvPHB device is going to be the base device for all other powernv PHBs. It consists of a device that has the same user API as the other PHB, namely being a PCIHostBridge and having chip-id and index properties. It also has a 'backend' pointer that will be initialized with the PHB implementation that the device is going to use. The initialization of the PHB backend is done by checking the PHB version via a 'version' attribute that can be set via a global machine property. The 'version' field will be used to make adjustments based on the running version, e.g. PHB3 uses a 'chip' reference while PHB4 uses 'pec'. To init the PnvPHB bus we'll rely on helpers for each version. The version 3 helper is already added (pnv_phb3_bus_init), the PHB4 helper will be added later on. For now let's add the basic logic of the PnvPHB object, which consists mostly of pnv_phb_realize() doing all the work of checking the phb->version set, initializing the proper backend, passing through its attributes to the chosen backend, finalizing the backend realize and adding a root port in the end. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-3-danielhb413@gmail.com>
| * | ppc/pnv: add PHB3 bus init helperDaniel Henrique Barboza2022-08-312-16/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PnvPHB3 bus init consists of initializing the pci_io and pci_mmio regions, registering it via pci_register_root_bus() and then setup the iommu. We'll want to init the bus from outside pnv_phb3.c when the bus is removed from the PnvPHB3 device and put into a new parent PnvPHB device. The new pnv_phb3_bus_init() helper will be used by the parent to init the bus when using the PHB3 backend. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-2-danielhb413@gmail.com>
| * | target/ppc: Bugfix FP when OE/UE are setLucas Mateus Castro (alqotel)2022-08-312-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an overflow exception occurs and OE is set the intermediate result should be adjusted (by subtracting from the exponent) to avoid rounding to inf. The same applies to an underflow exceptionion and UE (but adding to the exponent). To do this set the fp_status.rebias_overflow when OE is set and fp_status.rebias_underflow when UE is set as the FPU will recalculate in case of a overflow/underflow if the according rebias* is set. Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220805141522.412864-3-lucas.araujo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | fpu: Add rebias bool, value and operationLucas Mateus Castro (alqotel)2022-08-313-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added the possibility of recalculating a result if it overflows or underflows, if the result overflow and the rebias bool is true then the intermediate result should have 3/4 of the total range subtracted from the exponent. The same for underflow but it should be added to the exponent of the intermediate number instead. Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220805141522.412864-2-lucas.araujo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | ppc/pnv: Add initial P9/10 SBE modelNicholas Piggin2022-08-318-0/+524
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | target/ppc: Fix host PVR matching for KVMNicholas Piggin2022-08-304-24/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ppc_cpu_compare_class_pvr_mask() should match the best CPU class in the family, because it is used by the KVM subsystem to find the host CPU class. Since commit 03ae4133ab8 ("target-ppc: Add pvr_match() callback"), it matches any class in the family (the first one in the comparison list). Since commit f30c843ced5 ("ppc/pnv: Introduce PowerNV machines with fixed CPU models"), pnv has relied on pnv_match having these new semantics to check machine compatibility with a CPU family. Resolve this by adding a parameter to the pvr_match function to select the best or any match, and restore the old behaviour for the KVM case. Prior to this fix, e.g., a POWER9 DD2.3 KVM host matches to the power9_v1.0 class (because that happens to be the first POWER9 family CPU compared). After the patch, it matches the power9_v2.0 class. This approach requires pnv_match contain knowledge of the CPU classes implemented in the same family, which feels ugly. But pushing the 'best' match down to the class would still require they know about one another which is not obviously much better. For now this gets things working. Fixes: 03ae4133ab8 ("target-ppc: Add pvr_match() callback") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220731013358.170187-1-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
| * | pseries: Update SLOF firmware imageAlexey Kardashevskiy2022-08-304-2/+2
| |/ | | | | | | | | | | | | | | The only change is that now SLOF can also boot big endian zImage but kernel-addr=0 is still required. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
* | Merge tag 'testing-pull-request-2022-08-30' of https://gitlab.com/thuth/qemu ↵Stefan Hajnoczi2022-09-0166-79/+144
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging * First batch of patches to get qtests adapted for Windows * Two preparation patches for the upcoming removal of the slirp submodule * Some other small test fixes (typos, etc.) # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmMOVvcRHHRodXRoQHJl # ZGhhdC5jb20ACgkQLtnXdP5wLbUcOA//d4MU0VWbMRXHLLTvaIO+0I1JhiMP5PbU # qgDwGfIu7uY58hXvjDCSmoV5Lj35I/VdsmWYcC4dwQcIr9BwZq3H+jthB4sxMDIJ # UAnowmO22x5iTZr4PBY3GuYKRRUaf7EuqqOwmNAtrvDV+3BVn2sQFLtjWhqnyhqR # syonfyVhlFhqnFXPs6fXTXQxiuziuMmmHGSQMNRGuBudkivvOTQzElb3gxTp7pRe # FfIoAUVohUXptd26U+5Zr2KPxQQ/eZ2Elhnhjc6/r4u4JpbyfCQrGTFAMSuvq4HM # z/kKr/JA0v6vmX5ARjbCL0RhoNOM/DcOooxzX6YO3VkZTrQAHZxAsk25mihURRX3 # UgGLDlagNuPSTl1fkUuumH86fFQ54bFBFFOV3yJWQF5UDuWKoy3bPlSf5L0/bwRp # z5gYnf0lJxMG3kGgmaOnW4gj0Z0amn9AzI33BQDIldVNTHnp8/hNpscrsq5Voi2j # ot1G/aZt9OH+DeqAB8TJfbsHE8mtTgioihZ2QQOMAKVkF25UImFjNWliX8SUHG2h # E3ro9QLugV2FgIggJwRyN9w394hEn7BR8DMyiPCRemcjnT4Fuy9IoEBEkJ2gj3n4 # QiDPdrr/1dw8uApGBts3YyRbSmajqKUegXCuOYXjpU90f4Kno0WN2/jkTx8pvfcE # bJvG21nzrdY= # =MCyJ # -----END PGP SIGNATURE----- # gpg: Signature made Tue 30 Aug 2022 14:29:11 EDT # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "thuth@redhat.com" # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * tag 'testing-pull-request-2022-08-30' of https://gitlab.com/thuth/qemu: (23 commits) tests/avocado/migration: Get find_free_port() from the ports tests/qtest/ac97-test: Correct reference to driver gitlab-ci: Only use one process in Windows jobs for compilation docs/devel/testing: fix minor typo tests/avocado: Fix trivial typo tests/avocado: Do not run tests that require libslirp if it is not available tests/vm: Add libslirp to the VM tests tests/qtest: prom-env-test: Use double quotes to pass the prom-env option tests/qtest: npcm7xx_emc-test: Skip running test_{tx, rx} on win32 tests/qtest: machine-none-test: Use double quotes to pass the cpu option tests/qtest: device-plug-test: Reverse the usage of double/single quotes tests/qtest: libqos: Rename malloc.h to libqos-malloc.h tests/qtest: libqos: Drop inclusion of <sys/wait.h> tests/qtest: migration-test: Skip running test_migrate_fd_proto on win32 tests/qtest: i440fx-test: Skip running request_{bios, pflash} for win32 tests/qtest: Build cases that use memory-backend-file for posix only tests/qtest: Build e1000e-test for posix only tests/qtest: Adapt {m48t59,rtc}-test cases for win32 backends/tpm: Exclude headers and macros that don't exist on win32 tests/qtest: migration-test: Handle link() for win32 ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
| * | tests/avocado/migration: Get find_free_port() from the portsThomas Huth2022-08-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In upstream Avocado, the find_free_port() function is not available from "network" anymore, but must be used via "ports", see: https://github.com/avocado-framework/avocado/commit/22fc98c6ff76cc55c48 To be able to update to a newer Avocado version later, let's use the new way for accessing the find_free_port() function here. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220829121939.209329-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
| * | tests/qtest/ac97-test: Correct reference to driverAkihiko Odaki2022-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20220829083301.143527-1-akihiko.odaki@daynix.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
| * | gitlab-ci: Only use one process in Windows jobs for compilationThomas Huth2022-08-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Windows jobs are currently aborting at weird places - and there's the suspicion that it's due to memory constraints in the Windows containers. Let's switch to single-threaded compilation to decrease the pressure on the memory load, and to make the job more deterministic for further investigations. Message-Id: <20220825193323.104768-1-thuth@redhat.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
| * | docs/devel/testing: fix minor typoMatheus Tavares Bernardino2022-08-291-1/+1
| | | | | | | | | | | | | | | | | | Signed-off-by: Matheus Tavares Bernardino <quic_mathbern@quicinc.com> Message-Id: <421fb28678d1077c0b14978e359b4e1469cc0168.1661262376.git.quic_mathbern@quicinc.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
| * | tests/avocado: Fix trivial typoThomas Huth2022-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The intention was likely to use "intend" instead of "indent" here. Message-Id: <20220824080926.568935-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
| * | tests/avocado: Do not run tests that require libslirp if it is not availableThomas Huth2022-08-293-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some avocado tests blindly assume that QEMU has been compiled with libslirp enabled and fail badly if it is missing. Add a proper check to cancel the tests in this case. Message-Id: <20220824151122.704946-6-thuth@redhat.com> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-05 22:23:22 +0100