aboutsummaryrefslogtreecommitdiff
path: root/hw/ppc
AgeCommit message (Collapse)AuthorFilesLines
2022-01-12ppc/pnv: Introduce user creatable pnv-phb4 devicesDaniel Henrique Barboza1-0/+2
This patch introduces pnv-phb4 user creatable devices that are created in a similar manner as pnv-phb3 devices, allowing the user to interact with the PHBs directly instead of creating PCI Express Controllers that will create a certain amount of PHBs per controller index. We accomplish this by doing the following: - add a pnv_phb4_get_stack() helper to retrieve which stack an user created phb4 would occupy; - when dealing with an user created pnv-phb4 (detected by checking if phb->stack is NULL at the start of phb4_realize()), retrieve its stack and initialize its properties as done in stk_realize(); - use 'defaults_enabled()' in stk_realize() to avoid creating and initializing a 'stack->phb' qdev that might be overwritten by an user created pnv-phb4 device. This process is wrapped into a new helper called pnv_pec_stk_default_phb_realize(). Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Move num_phbs under Pnv8ChipCédric Le Goater1-4/+3
It is not used elsewhere so that's where it belongs. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-10-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Complete user created PHB3 devicesCédric Le Goater1-0/+2
PHB3s ared SysBus devices and should be allowed to be dynamically created. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-9-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Reparent user created PHB3 devices to the PnvChipCédric Le Goater1-0/+17
The powernv machine uses the object hierarchy to populate the device tree and each device should be parented to the chip it belongs to. This is not the case for user created devices which are parented to the container "/unattached". Make sure a PHB3 device is parented to its chip by reparenting the object if necessary. 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: <20220105212338.49899-8-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Introduce support for user created PHB3 devicesCédric Le Goater1-5/+18
PHB3 devices and PCI devices can now be added to the powernv8 machine using : -device pnv-phb3,chip-id=0,index=1 \ -device nec-usb-xhci,bus=pci.1,addr=0x0 The 'index' property identifies the PHB3 in the chip. In case of user created devices, a lookup on 'chip-id' is required to assign the owning chip. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-7-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Attach PHB3 root port device when defaults are enabledCédric Le Goater1-0/+8
This cleanups the PHB3 model a bit more since the root port is an independent device and it will ease our task when adding user created PHB3s. pnv_phb_attach_root_port() is made public in pnv.c so it can be reused with the pnv_phb4 root port later. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12spapr: Fix support of POWER5+ processorsCédric Le Goater1-4/+6
POWER5+ (ISA v2.03) processors are supported by the pseries machine but they do not have Altivec instructions. Do not advertise support for it in the DT. To be noted that this test is in contradiction with the assert in cap_vsx_apply(). Signed-off-by: Cédric Le Goater <clg@kaod.org> Tested-by: Fabiano Rosas <farosas@linux.ibm.com> Message-Id: <20220105095142.3990430-3-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-05hw: Add compat machines for 7.0Cornelia Huck1-2/+13
Add 7.0 machine types for arm/i440fx/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211217143948.289995-1-cohuck@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-01-04ppc/ppc405: Fix timer initializationCédric Le Goater1-2/+0
Timers are already initialized in ppc4xx_init(). No need to do it a second time with a wrong set. Fixes: d715ea961254 ("PPC: 405: Fix ppc405ep initialization") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211222064025.1541490-7-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220103063441.3424853-8-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-04ppc/ppc405: Rework ppc_40x_timers_init() to use a PowerPCCPUCédric Le Goater1-23/+19
This is a small cleanup to ease reading. It includes the removal of a check done on the returned value of g_malloc0(), which can not fail. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211222064025.1541490-6-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220103063441.3424853-7-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 Goater2-0/+27
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>
2022-01-04ppc/ppc4xx: Convert printfs()Cédric Le Goater4-35/+29
Use a QEMU log primitive for errors and trace events for debug. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.drobear.id.au> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20211222064025.1541490-3-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220103063441.3424853-4-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-04ppc/pnv: Change the maximum of PHB3 devices for Power8NVLCédric Le Goater1-1/+1
The POWER8 processors with a NVLink logic unit have 4 PHB3 devices per chip. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211222063817.1541058-2-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Use QOM hierarchy to scan PEC PHB4 devicesCédric Le Goater1-7/+13
When -nodefaults is supported for PHB4 devices, the pecs array under the chip will be empty. This will break the 'info pic' HMP command. Do a QOM loop on the chip children and look for PEC PHB4 devices instead. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211213132830.108372-15-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Move realize of PEC stacks under the PEC modelCédric Le Goater1-33/+4
This change will help us providing support for user created PHB4 devices. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211213132830.108372-14-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Remove "system-memory" property from PHB4 PECCédric Le Goater1-2/+0
This is not useful and will be in the way for support of user created PHB4 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: <20211213132830.108372-13-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Compute the PHB index from the PHB4 PEC modelCédric Le Goater1-3/+1
Use the num_stacks class attribute to compute the PHB index depending on the PEC index : * PEC0 provides 1 PHB (PHB0) * PEC1 provides 2 PHBs (PHB1 and PHB2) * PEC2 provides 3 PHBs (PHB3, PHB4 and PHB5) The routine pnv_pec_phb_offset() is a bit complex but it also prepares ground for PHB5 which has a different layout of stacks: 3 per PECs. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211213132830.108372-12-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Introduce a num_stack class attributeCédric Le Goater1-7/+0
Each PEC device of the POWER9 chip has a predefined number of stacks, equivalent of a root port complex: PEC0 -> 1 stack PEC1 -> 2 stacks PEC2 -> 3 stacks Introduce a class attribute to hold these values and remove the "num-stacks" property. 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: <20211213132830.108372-11-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Introduce a "chip" property under the PHB4 modelCédric Le Goater1-0/+2
And check the PEC index using the chip class. 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: <20211213132830.108372-10-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Introduce version and device_id class atributes for PHB4 devicesCédric Le Goater1-2/+2
It prepares ground for PHB5 which has different values. 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: <20211213132830.108372-9-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Introduce a num_pecs class attribute for PHB4 PEC devicesCédric Le Goater1-11/+8
POWER9 processor comes with 3 PHB4 PEC (PCI Express Controller) and each PEC can have several PHBs : * PEC0 provides 1 PHB (PHB0) * PEC1 provides 2 PHBs (PHB1 and PHB2) * PEC2 provides 3 PHBs (PHB3, PHB4 and PHB5) A num_pecs class attribute represents better the logic units of the POWER9 chip. Use that instead of num_phbs which fits POWER8 chips. This will ease adding support for user created devices. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211213132830.108372-8-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Use QOM hierarchy to scan PHB3 devicesCédric Le Goater1-18/+54
When -nodefaults is supported for PHB3 devices, the phbs array under the chip will be empty. This will break the XICSFabric handlers, and all interrupt delivery, and the 'info pic' HMP command. Do a QOM loop on the chip children and look for PHB3 devices instead. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211213132830.108372-7-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Move mapping of the PHB3 CQ regions under pnv_pbcq_realize()Cédric Le Goater1-12/+0
This change will help us providing 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: <20211213132830.108372-6-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Drop the "num-phbs" propertyCédric Le Goater1-1/+0
It is never used. 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: <20211213132830.108372-5-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Introduce a "chip" property under PHB3Cédric Le Goater1-0/+2
This change will help us move the mapping of XSCOM regions under the PHB3 realize routine, which will be necessary 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: <20211213132830.108372-3-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17target/ppc: introduce PMUEventType and PMU overflow timersDaniel Henrique Barboza1-0/+1
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-17ppc/ppc405: Add update of bi_procfreq fieldCédric Le Goater1-4/+5
Adapt the fields offset in the board information for Linux. Since Linux relies on the CPU frequency value, I wonder how it ever worked. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-15-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Fix bi_pci_enetaddr2 field in U-Boot board informationCédric Le Goater1-1/+1
The board information for the 405EP first appeared in commit 04f20795ac81 ("Move PowerPC 405 specific definitions into a separate file ...") An Ethernet address is a 6 byte number. Fix that. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211206103712.1866296-14-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Change default PLL values at resetCédric Le Goater1-3/+3
These values are computed and updated by U-Boot at startup. Use them as defaults to improve direct Linux boot. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-13-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Fix boot from kernelCédric Le Goater1-43/+102
The machine can already boot with kernel and initrd U-boot images if a firmware is loaded first. Adapt and improve the load sequence to let the machine boot directly from a Linux kernel ELF image and a usual initrd image if a firmware image is not provided. For that, install a custom CPU reset handler to setup the registers and to start the CPU from the Linux kernel entry point. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-12-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Introduce ppc405_set_default_bootinfo()Cédric Le Goater3-29/+42
This routine is a small helper to cleanup the code. The update of the flash fields were removed because there are not of any use when booting from a Linux kernel image. It should be functionally equivalent. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-11-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Rework FW loadCédric Le Goater1-25/+20
QEMU installs a custom U-Boot in-memory descriptor to share board information with Linux, which means that the QEMU machine was initially designed to support booting Linux directly without using the loaded FW. But, it's not that simple because the CPU still starts at address 0xfffffffc where nothing is currently mapped. Support must have been broken these last years. Since we can not find a "ppc405_rom.bin" firmware file, request one to be specified on the command line. A consequence of this change is that the machine can be booted directly from Linux without any FW being loaded. This is still broken and the CPU start address will be fixed in the next changes. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-10-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Remove flash supportCédric Le Goater1-13/+1
It is currently impossible to find a "ppc405_rom.bin" firmware file or a full flash image for the PPC405EP evalution board. Even if it should be technically possible to recreate such an image, it's unlikely that anyone will do it since the board is obsolete and support in QEMU has been broken for about 10 years. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-9-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Add some address space definitionsCédric Le Goater2-9/+14
Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211206103712.1866296-8-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Change ppc405ep_init() return valueCédric Le Goater3-4/+8
I will be useful to rework the boot from Linux. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-7-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Drop flag parameter in ppc405_set_bootinfo()Cédric Le Goater3-8/+5
It was introduced in commit b8d3f5d12642 ("Add flags to support PowerPC 405 bootinfos variations.") but since its value has always been set to '1'. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211206103712.1866296-6-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Convert printfs to trace-eventsCédric Le Goater2-105/+74
and one error message to a LOG_GUEST_ERROR. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-5-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc: Add trace-events for DCR accessesCédric Le Goater2-0/+5
Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211206103712.1866296-4-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc: Mark the 'taihu' machine as deprecatedThomas Huth1-0/+1
The PPC 405 CPU is a system-on-a-chip, so all 405 machines are very similar, except for some external periphery. However, the periphery of the 'taihu' machine is hardly emulated at all (e.g. neither the LCD nor the USB part had been implemented), so there is not much value added by this board. The users can use the 'ref405ep' machine to test their PPC405 code instead. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211203164904.290954-2-thuth@redhat.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-3-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Change kernel load addressCédric Le Goater1-1/+1
The default addresses to load the kernel, fdt, initrd of AMCC boards in U-Boot v2015.10 are : "kernel_addr_r=1000000\0" "fdt_addr_r=1800000\0" "ramdisk_addr_r=1900000\0" The taihu is one of these boards, the ref405ep is not but we don't have much information on it and both boards have a very similar address space layout. Also, if loaded at address 0, U-Boot will partially overwrite the uImage because of a bug in get_ram_size() (U-Boot v2015.10) not restoring properly the probed RAM contents and because the exception vectors are installed in the same range. Finally, a gzipped kernel image will be uncompressed at 0x0. These are all good reasons for not mappping a kernel image at this address. Change the kernel load address to match U-Boot expectations and fix loading. Cc: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20211202191446.1292125-1-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-2-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv.c: fix "system-id" FDT when -uuid is setDaniel Henrique Barboza1-1/+1
Setting -uuid in the pnv machine does not work: ./qemu-system-ppc64 -machine powernv8,accel=tcg -uuid 7ff61ca1-a4a0-4bc1-944c-abd114a35e80 qemu-system-ppc64: error creating device tree: (fdt_property_string(fdt, "system-id", buf)): FDT_ERR_BADSTATE This happens because we're using fdt_property_string(), which is a sequential write function that is supposed to be used when we're building a new FDT, in a case where read/writing into an existing FDT. Fix it by using fdt_setprop_string() instead. Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211207094858.744386-1-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv.c: add a friendly warning when accel=kvm is usedDaniel Henrique Barboza1-0/+5
If one tries to use -machine powernv9,accel=kvm in a Power9 host, a cryptic error will be shown: qemu-system-ppc64: Register sync failed... If you're using kvm-hv.ko, only "-cpu host" is possible qemu-system-ppc64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument Appending '-cpu host' will throw another error: qemu-system-ppc64: invalid chip model 'host' for powernv9 machine The root cause is that in IBM PowerPC we have different specs for the bare-metal and the guests. The bare-metal follows OPAL, the guests follow PAPR. The kernel KVM modules presented in the ppc kernels implements PAPR. This means that we can't use KVM accel when using the powernv machine, which is the emulation of the bare-metal host. All that said, let's give a more informative error in this case. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20211130133153.444601-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17hw/ppc/mac.h: Remove MAX_CPUS macroPeter Maydell3-5/+4
The mac.h header defines a MAX_CPUS macro. This is confusingly named, because it suggests it's a generic setting, but in fact it's used by only the g3beige and mac99 machines. It's also using a single macro for two values which aren't inherently the same -- if one of these two machines was updated to support SMP configurations then it would want a different max_cpus value to the other. Since the macro is used in only two places, just expand it out and get rid of it. If hypothetical future work to support SMP in these boards needs a compile-time-known limit on the number of CPUs, we can give it a suitable name at that point. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211105184216.120972-1-peter.maydell@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-11-29target/ppc: fix Hash64 MMU update of PTE bit RLeandro Lupori2-5/+5
When updating the R bit of a PTE, the Hash64 MMU was using a wrong byte offset, causing the first byte of the adjacent PTE to be corrupted. This caused a panic when booting FreeBSD, using the Hash MMU. Fixes: a2dd4e83e76b ("ppc/hash64: Rework R and C bit updates") Signed-off-by: Leandro Lupori <leandro.lupori@eldorado.org.br> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-11-10spapr_numa.c: fix FORM1 distance-less nodesDaniel Henrique Barboza1-31/+31
Commit 71e6fae3a99 fixed an issue with FORM2 affinity guests with NUMA nodes in which the distance info is absent in machine_state->numa_state->nodes. This happens when QEMU adds a default NUMA node and when the user adds NUMA nodes without specifying the distances. During the discussions of the forementioned patch [1] it was found that FORM1 guests were behaving in a strange way in the same scenario, with the kernel seeing the distances between the nodes as '160', as we can see in this example with 4 NUMA nodes without distance information: $ numactl -H available: 4 nodes (0-3) (...) node distances: node 0 1 2 3 0: 10 160 160 160 1: 160 10 160 160 2: 160 160 10 160 3: 160 160 160 10 Turns out that we have the same problem with FORM1 guests - we are calculating associativity domain using zeroed values. And as it also turns out, the solution from 71e6fae3a99 applies to FORM1 as well. This patch creates a wrapper called 'get_numa_distance' that contains the logic used in FORM2 to define node distances when this information is absent. This helper is then used in all places where we need to read distance information from machine_state->numa_state->nodes. That way we'll guarantee that the NUMA node distance is always being curated before being used. After this patch, the FORM1 guest mentioned above will have the following topology: $ numactl -H available: 4 nodes (0-3) (...) node distances: node 0 1 2 3 0: 10 20 20 20 1: 20 10 20 20 2: 20 20 10 20 3: 20 20 20 10 This is compatible with what FORM2 guests and other archs do in this case. [1] https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg01960.html Fixes: 690fbe4295d5 ("spapr_numa: consider user input when defining associativity") CC: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> CC: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-11-09spapr_numa.c: FORM2 table handle nodes with no distance infoNicholas Piggin1-5/+17
A configuration that specifies multiple nodes without distance info results in the non-local points in the FORM2 matrix having a distance of 0. This causes Linux to complain "Invalid distance value range" because a node distance is smaller than the local distance. Fix this by building a simple local / remote fallback for points where distance information is missing. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20211105135137.1584840-1-npiggin@gmail.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-11-09ppc/pegasos2: Suppress warning when qtest enabledBALATON Zoltan1-1/+2
Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20211101151023.F0D02748F5A@zero.eik.bme.hu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-11-09ppc/pnv: Fix check on block device before updating drive contentsCédric Le Goater1-1/+1
Test is wrong and the backend can never updated. It could have led to a QEMU crash but since the firmware deactivates flash access if a valid layout is not detected, it went unnoticed. Reported-by: Coverity CID 1465223 Fixes: 35dde5766211 ("ppc/pnv: Add a PNOR model") Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211102162905.762078-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-11-01pci: Export pci_for_each_device_under_bus*()Peter Xu3-13/+10
They're actually more commonly used than the helper without _under_bus, because most callers do have the pci bus on hand. After exporting we can switch a lot of the call sites to use these two helpers. Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20211028043129.38871-3-peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au>
2021-10-21hw/ppc/ppc4xx_pci: Fix ppc4xx_pci_map_irq() for recent Linux kernelsThomas Huth1-3/+5
Recent Linux kernels are accessing the PCI device in slot 0 that represents the PCI host bridge. This causes ppc4xx_pci_map_irq() to return -1 which causes an assert() later: hw/pci/pci.c:262: pci_bus_change_irq_level: Assertion `irq_num >= 0' failed. Thus we should allocate an IRQ line for the device in slot 0, too. To avoid changes to the outside of ppc4xx_pci.c, we map it to the internal IRQ number 4 which will then happily be ignored since ppc440_bamboo.c does not wire it up. With these changes it is now possible again to use recent Linux kernels for the bamboo board. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20211019091817.469003-1-thuth@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
generated by cgit v1.1 at 2024-11-01 00:08:27 +0000