aboutsummaryrefslogtreecommitdiff
path: root/hw/ppc
AgeCommit message (Collapse)Author
2021-12-17ppc/pnv: Move realize of PEC stacks under the PEC modelCédric Le Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Barboza
This patch starts an IBM Power8+ compatible PMU implementation by adding the representation of PMU events that we are going to sample, PMUEventType. This enum represents a Perf event that is being sampled by a specific counter 'sprn'. Events that aren't available (i.e. no event was set in MMCR1) will be of type 'PMU_EVENT_INVALID'. Events that are inactive due to frozen counter bits state are of type 'PMU_EVENT_INACTIVE'. Other types added in this patch are PMU_EVENT_CYCLES and PMU_EVENT_INSTRUCTIONS. More types will be added later on. Let's also add the required PMU cycle overflow timers. They will be used to trigger cycle overflows when cycle events are being sampled. This timer will call cpu_ppc_pmu_timer_cb(), which in turn calls fire_PMC_interrupt(). Both functions are stubs that will be implemented later on when EBB support is added. Two new helper files are created to host this new logic. cpu_ppc_pmu_init() will init all overflow timers during CPU init time. Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211201151734.654994-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Add update of bi_procfreq fieldCédric Le Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Goater
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 Huth
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 Goater
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 Barboza
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 Barboza
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 Maydell
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 Lupori
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 Barboza
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 Piggin
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 Zoltan
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 Goater
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 Xu
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 Huth
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>
2021-10-21ppc/pegasos2: Implement power-off RTAS function with VOFBALATON Zoltan
This only helps Linux guests as only that seems to use it. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <1c1e030f2bbc86e950b3310fb5922facdc21ef86.1634241019.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-10-21ppc/pegasos2: Add constants for PCI config addressesBALATON Zoltan
Define a constant for PCI config addresses to make it clearer what these numbers are. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <9bd8e84d02d91693b71082a1fadeb86e6bce3025.1634241019.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-10-21ppc/pegasos2: Access MV64361 registers via their memory regionBALATON Zoltan
Instead of relying on the mapped address of the MV64361 registers access them via their memory region. This is not a problem at reset time when these registers are mapped at the default address but the guest could change this later and then the RTAS calls accessing PCI config registers could fail. None of the guests actually do this so this only avoids a theoretical problem not seen in practice. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <b6f768023603dc2c4d130720bcecdbea459b7668.1634241019.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-10-21ppc/pegasos2: Implement get-time-of-day RTAS function with VOFBALATON Zoltan
This is needed for Linux to access RTC time. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <6233eb07c680d6c74427e11b9641958f98d53378.1634241019.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-10-21ppc/pegasos2: Warn when using VOF but no kernel is specifiedBALATON Zoltan
Issue a warning when using VOF (which is the default) but no -kernel option given to let users know that it will likely fail as the guest has nothing to run. It is not a hard error because it may still be useful to start the machine without further options for testing or inspecting it from monitor without actually booting it. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <a4ec9a900df772b91e9f69ca7a0799d8ae293e5a.1634241019.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-10-21ppc/pegasos2: Restrict memory to 2 gigabytesBALATON Zoltan
The CHRP spec this board confirms to only allows 2 GiB of system memory below 4 GiB as the high 2 GiB is allocated to IO and system resources. To avoid problems with memory overlapping these areas restrict RAM to 2 GiB similar to mac_newworld. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <54f58229a69c9c1cca21bcecad700b3d7052edd5.1634241019.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-10-21hw/ppc: Fix iothread locking in the 405 codeThomas Huth
When using u-boot as firmware with the taihu board, QEMU aborts with this assertion: ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) Running QEMU with "-d in_asm" shows that the crash happens when writing to SPR 0x3f2, so we are missing to lock the iothread in the code path here. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20211006071140.565952-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>
2021-10-21hw/ppc/spapr_softmmu: Reduce include listPhilippe Mathieu-Daudé
Commit 962104f0448 ("hw/ppc: moved hcalls that depend on softmmu") introduced a lot of unnecessary #include directives. Remove them. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211006170801.178023-1-philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-10-21target/ppc: Fix the test raising the decrementer exceptionCédric Le Goater
Commit 4d9b8ef9b5ab ("target/ppc: Fix 64-bit decrementer") introduced new int64t variables and broke the test triggering the decrementer exception. Revert partially the change to evaluate both clause of the if statement. Reported-by: Coverity CID 1464061 Fixes: 4d9b8ef9b5ab ("target/ppc: Fix 64-bit decrementer") Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211005053324.441132-1-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-10-15qdev: Make DeviceState.id independent of QemuOptsKevin Wolf
DeviceState.id is a pointer to a string that is stored in the QemuOpts object DeviceState.opts and freed together with it. We want to create devices without going through QemuOpts in the future, so make this a separately allocated string. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20211008133442.141332-9-kwolf@redhat.com> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-10-01machine: Move smp_prefer_sockets to struct SMPCompatPropsYanan Wang
Now we have a common structure SMPCompatProps used to store information about SMP compatibility stuff, so we can also move smp_prefer_sockets there for cleaner code. No functional change intended. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-15-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-01machine: Prefer cores over sockets in smp parsing since 6.2Yanan Wang
In the real SMP hardware topology world, it's much more likely that we have high cores-per-socket counts and few sockets totally. While the current preference of sockets over cores in smp parsing results in a virtual cpu topology with low cores-per-sockets counts and a large number of sockets, which is just contrary to the real world. Given that it is better to make the virtual cpu topology be more reflective of the real world and also for the sake of compatibility, we start to prefer cores over sockets over threads in smp parsing since machine type 6.2 for different arches. In this patch, a boolean "smp_prefer_sockets" is added, and we only enable the old preference on older machines and enable the new one since type 6.2 for all arches by using the machine compat mechanism. Suggested-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-10-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30Merge remote-tracking branch ↵Peter Maydell
'remotes/pmaydell/tags/pull-target-arm-20210930' into staging target-arm queue: * allwinner-h3: Switch to SMC as PSCI conduit * arm: tcg: Adhere to SMCCC 1.3 section 5.2 * xlnx-zcu102, xlnx-versal-virt: Support BBRAM and eFUSE devices * gdbstub related code cleanups * Don't put FPEXC and FPSID in org.gnu.gdb.arm.vfp XML * Use _init vs _new convention in bus creation function names * sabrelite: Connect SPI flash CS line to GPIO3_19 # gpg: Signature made Thu 30 Sep 2021 16:11:20 BST # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20210930: (22 commits) hw/arm: sabrelite: Connect SPI flash CS line to GPIO3_19 ide: Rename ide_bus_new() to ide_bus_init() qbus: Rename qbus_create() to qbus_new() qbus: Rename qbus_create_inplace() to qbus_init() pci: Rename pci_root_bus_new_inplace() to pci_root_bus_init() ipack: Rename ipack_bus_new_inplace() to ipack_bus_init() scsi: Replace scsi_bus_new() with scsi_bus_init(), scsi_bus_init_named() target/arm: Don't put FPEXC and FPSID in org.gnu.gdb.arm.vfp XML target/arm: Move gdbstub related code out of helper.c target/arm: Fix coding style issues in gdbstub code in helper.c configs: Don't include 32-bit-only GDB XML in aarch64 linux configs docs/system/arm: xlnx-versal-virt: BBRAM and eFUSE Usage hw/arm: xlnx-zcu102: Add Xilinx eFUSE device hw/arm: xlnx-zcu102: Add Xilinx BBRAM device hw/arm: xlnx-versal-virt: Add Xilinx eFUSE device hw/arm: xlnx-versal-virt: Add Xilinx BBRAM device hw/nvram: Introduce Xilinx battery-backed ram hw/nvram: Introduce Xilinx ZynqMP eFuse device hw/nvram: Introduce Xilinx Versal eFuse device hw/nvram: Introduce Xilinx eFuse QOM ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30qbus: Rename qbus_create() to qbus_new()Peter Maydell
Rename the "allocate and return" qbus creation function to qbus_new(), to bring it into line with our _init vs _new convention. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Corey Minyard <cminyard@mvista.com> Message-id: 20210923121153.23754-6-peter.maydell@linaro.org
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-16 02:17:18 +0000