aboutsummaryrefslogtreecommitdiff
path: root/hw/ppc
AgeCommit message (Collapse)AuthorFilesLines
2021-07-20hw/ppc/Kconfig: Add dependency PEGASOS2 -> ATI_VGAPhilippe Mathieu-Daudé1-0/+1
The ATI VGA device isn't a requisite for the Pegasos2 machine because Linux only uses the serial console; see commit ba7e5ac18e7 ("hw/ppc: Add emulation of Genesi/bPlan Pegasos II") for rationale. Using the default devices we don't have any problem: $ qemu-system-ppc -M pegasos2 qemu-system-ppc: standard VGA not available But when trying to explicitly use the ATI device we get an error: $ qemu-system-ppc -M pegasos2 -vga none -bios pegasos2.rom -device ati-vga,romfile= qemu-system-ppc: -device ati-vga,romfile=: 'ati-vga' is not a valid device model name Add it as an implicit Kconfig dependency. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210515173716.358295-13-philmd@redhat.com> Acked-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-20hw/ppc/Kconfig: Add missing dependency E500 -> DS1338 RTCPhilippe Mathieu-Daudé1-0/+1
Commit 7abb479c7ab ("PPC: E500: Add FSL I2C controller and integrate RTC with it") added a global dependency on the DS1338 model, instead of a machine one (via Kconfig). This gives trouble when building standalone machines not exposing I2C bus: The following clauses were found for DS1338 CONFIG_DS1338=y config DS1338 depends on I2C Fix by selecting the DS1338 symbol in the single machine requiring it, the E500. Fixes: 7abb479c7ab ("PPC: E500: Add FSL I2C controller and integrate RTC with it") Acked-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210513163858.3928976-9-philmd@redhat.com>
2021-07-13ppc/pegasos2: Allow setprop in VOFBALATON Zoltan1-0/+10
Linux needs setprop to fix up the device tree, otherwise it's not finding devices and cannot boot. Since recent VOF change now we need to add a callback to allow this which is what this patch does. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20210709132920.6544E7457EF@zero.eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-12Merge remote-tracking branch 'remotes/philmd/tags/mips-20210711' into stagingPeter Maydell1-1/+1
MIPS patches queue - Rename Raven ASIC PCI bridge, add PCI_IO_BASE_ADDR definition - Various Toshiba TX79 opcodes implemented - Rewrite UHI errno_mips() using switch statement - Few fixes and improvements in the SONIC model (dp8393x) # gpg: Signature made Sun 11 Jul 2021 22:12:49 BST # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full] # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * remotes/philmd/tags/mips-20210711: dp8393x: don't force 32-bit register access dp8393x: Rewrite dp8393x_get() / dp8393x_put() dp8393x: Store CAM registers as 16-bit dp8393x: Replace 0x40 magic value by SONIC_REG_COUNT definition dp8393x: Replace address_space_rw(is_write=1) by address_space_write() dp8393x: fix CAM descriptor entry index target/mips: Rewrite UHI errno_mips() using switch statement target/mips/tx79: Introduce SQ opcode (Store Quadword) target/mips/tx79: Introduce LQ opcode (Load Quadword) target/mips/tx79: Introduce PROT3W opcode (Parallel Rotate 3 Words) target/mips/tx79: Introduce PPACW opcode (Parallel Pack to Word) target/mips/tx79: Introduce PCGT* (Parallel Compare for Greater Than) target/mips/tx79: Introduce PCEQ* opcodes (Parallel Compare for Equal) target/mips/tx79: Introduce PEXTL[BHW] opcodes (Parallel Extend Lower) target/mips/tx79: Introduce PEXTUW (Parallel Extend Upper from Word) target/mips/tx79: Introduce PSUB* opcodes (Parallel Subtract) target/mips/tx79: Introduce PAND/POR/PXOR/PNOR opcodes (parallel logic) hw/pci-host/raven: Add PCI_IO_BASE_ADDR definition hw/pci-host: Rename Raven ASIC PCI bridge as raven.c Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-11Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into ↵Peter Maydell1-1/+1
staging * More SVM fixes (Lara) * Module annotation database (Gerd) * Memory leak fixes (myself) * Build fixes (myself) * --with-devices-* support (Alex) # gpg: Signature made Fri 09 Jul 2021 17:23:52 BST # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini-gitlab/tags/for-upstream: (48 commits) meson: Use input/output for entitlements target configure: allow the selection of alternate config in the build configs: rename default-configs to configs and reorganise hw/arm: move CONFIG_V7M out of default-devices hw/arm: add dependency on OR_IRQ for XLNX_VERSAL meson: Introduce target-specific Kconfig meson: switch function tests from compilation to linking vl: fix leak of qdict_crumple return value target/i386: fix exceptions for MOV to DR target/i386: Added DR6 and DR7 consistency checks target/i386: Added MSRPM and IOPM size check monitor/tcg: move tcg hmp commands to accel/tcg, register them dynamically usb: build usb-host as module monitor/usb: register 'info usbhost' dynamically usb: drop usb_host_dev_is_scsi_storage hook monitor: allow register hmp commands accel: build tcg modular accel: add tcg module annotations accel: build qtest modular accel: add qtest module annotations ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-11hw/pci-host: Rename Raven ASIC PCI bridge as raven.cPhilippe Mathieu-Daudé1-1/+1
The ASIC PCI bridge chipset from Motorola is named 'Raven'. This chipset is used in the PowerPC Reference Platform (PReP), but not restricted to it. Rename it accordingly. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20210417103028.601124-5-f4bug@amsat.org>
2021-07-09usb: drop usb_host_dev_is_scsi_storage hookGerd Hoffmann1-1/+1
Introduce an usb device flag instead, set it when usb-host looks at the device descriptors anyway. Also set it for emulated storage devices, for consistency. Add an inline helper function to check the flag. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Jose R. Ziviani <jziviani@suse.de> Message-Id: <20210624103836.2382472-32-kraxel@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-07-09target/ppc: Support for H_RPT_INVALIDATE hcallBharata B Rao2-0/+47
If KVM_CAP_RPT_INVALIDATE KVM capability is enabled, then - indicate the availability of H_RPT_INVALIDATE hcall to the guest via ibm,hypertas-functions property. - Enable the hcall Both the above are done only if the new sPAPR machine capability cap-rpt-invalidate is set. Signed-off-by: Bharata B Rao <bharata@linux.ibm.com> Message-Id: <20210706112440.1449562-3-bharata@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09spapr: Fix implementation of Open Firmware client interfaceAlexey Kardashevskiy4-34/+43
This addresses the comments from v22. The functional changes are (the VOF ones need retesting with Pegasos2): (VOF) setprop will start failing if the machine class callback did not handle it; (VOF) unit addresses are lowered in path_offset(); (SPAPR) /chosen/bootargs is initialized from kernel_cmdline if the client did not change it. Fixes: 5c991e5d4378 ("spapr: Implement Open Firmware client interface") Cc: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20210708065625.548396-1-aik@ozlabs.ru> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09ppc/pegasos2: Implement some RTAS functions with VOFBALATON Zoltan1-0/+137
Linux uses RTAS functions to access PCI devices so we need to provide these with VOF. Implement some of the most important functions to allow booting Linux with VOF. With this the board is now usable without a binary ROM image and we can enable it by default as other boards. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20210708215113.B3F747456E3@zero.eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09ppc/pegasos2: Fix use of && instead of &David Gibson1-1/+1
This is obviously intended to be a mask, not a logical operation. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09ppc/pegasos2: Use Virtual Open Firmware as firmware replacementBALATON Zoltan2-2/+601
The pegasos2 board comes with an Open Firmware compliant ROM based on SmartFirmware but it has some changes that are not open source therefore the ROM binary cannot be included in QEMU. Guests running on the board however depend on services provided by the firmware. The Virtual Open Firmware recently added to QEMU implements a minimal set of these services to allow some guests to boot without the original firmware. This patch adds VOF as the default firmware for pegasos2 which allows booting Linux and MorphOS via -kernel option while a ROM image can still be used with -bios for guests that don't run with VOF. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <1d6ed6f290c5c1f0b5a1e1c51cf1151452d70d9a.1624811233.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09target/ppc/spapr: Update H_GET_CPU_CHARACTERISTICS L1D cache flush bitsNicholas Piggin1-0/+2
There are several new L1D cache flush bits added to the hcall which reflect hardware security features for speculative cache access issues. These behaviours are now being specified as negative in order to simplify patched kernel compatibility with older firmware (a new problem found in existing systems would automatically be vulnerable). [dwg: Technically this changes behaviour for existing machine types. After discussion with Nick, we've determined this is safe, because the worst that will happen if a guest gets the wrong information due to a migration is that it will perform some unnecessary workarounds, but will remain correct and secure (well, as secure as it was going to be anyway). In addition the change only affects cap-cfpc=safe which is not enabled by default, and in fact is not possible to set on any current hardware (though it's expected it will be possible on POWER10)] Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20210615044107.1481608-1-npiggin@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09ppc/pegasos2: Introduce Pegasos2MachineState structureBALATON Zoltan1-13/+37
Add own machine state structure which will be used to store state needed for firmware emulation. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <7f6d5fbf4f70c64dba001483174a2921dd616ecd.1624811233.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09spapr: Implement Open Firmware client interfaceAlexey Kardashevskiy7-10/+1315
The PAPR platform describes an OS environment that's presented by a combination of a hypervisor and firmware. The features it specifies require collaboration between the firmware and the hypervisor. Since the beginning, the runtime component of the firmware (RTAS) has been implemented as a 20 byte shim which simply forwards it to a hypercall implemented in qemu. The boot time firmware component is SLOF - but a build that's specific to qemu, and has always needed to be updated in sync with it. Even though we've managed to limit the amount of runtime communication we need between qemu and SLOF, there's some, and it has become increasingly awkward to handle as we've implemented new features. This implements a boot time OF client interface (CI) which is enabled by a new "x-vof" pseries machine option (stands for "Virtual Open Firmware). When enabled, QEMU implements the custom H_OF_CLIENT hcall which implements Open Firmware Client Interface (OF CI). This allows using a smaller stateless firmware which does not have to manage the device tree. The new "vof.bin" firmware image is included with source code under pc-bios/. It also includes RTAS blob. This implements a handful of CI methods just to get -kernel/-initrd working. In particular, this implements the device tree fetching and simple memory allocator - "claim" (an OF CI memory allocator) and updates "/memory@0/available" to report the client about available memory. This implements changing some device tree properties which we know how to deal with, the rest is ignored. To allow changes, this skips fdt_pack() when x-vof=on as not packing the blob leaves some room for appending. In absence of SLOF, this assigns phandles to device tree nodes to make device tree traversing work. When x-vof=on, this adds "/chosen" every time QEMU (re)builds a tree. This adds basic instances support which are managed by a hash map ihandle -> [phandle]. Before the guest started, the used memory is: 0..e60 - the initial firmware 8000..10000 - stack 400000.. - kernel 3ea0000.. - initramdisk This OF CI does not implement "interpret". Unlike SLOF, this does not format uninitialized nvram. Instead, this includes a disk image with pre-formatted nvram. With this basic support, this can only boot into kernel directly. However this is just enough for the petitboot kernel and initradmdisk to boot from any possible source. Note this requires reasonably recent guest kernel with: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df5be5be8735 The immediate benefit is much faster booting time which especially crucial with fully emulated early CPU bring up environments. Also this may come handy when/if GRUB-in-the-userspace sees light of the day. This separates VOF and sPAPR in a hope that VOF bits may be reused by other POWERPC boards which do not support pSeries. This assumes potential support for booting from QEMU backends such as blockdev or netdev without devices/drivers used. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20210625055155.2252896-1-aik@ozlabs.ru> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> [dwg: Adjusted some includes which broke compile in some more obscure compilation setups] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-09spapr: tune rtas-sizeAlexey Kardashevskiy1-2/+6
QEMU reserves space for RTAS via /rtas/rtas-size which tells the client how much space the RTAS requires to work which includes the RTAS binary blob implementing RTAS runtime. Because pseries supports FWNMI which requires plenty of space, QEMU reserves more than 2KB which is enough for the RTAS blob as it is just 20 bytes (under QEMU). Since FWNMI reset delivery was added, RTAS_SIZE macro is not used anymore. This replaces RTAS_SIZE with RTAS_MIN_SIZE and uses it in the /rtas/rtas-size calculation to account for the RTAS blob. Fixes: 0e236d347790 ("ppc/spapr: Implement FWNMI System Reset delivery") Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20210622070336.1463250-1-aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-06-03ppc/pef.c: initialize cgs->ready in kvmppc_svm_init()Daniel Henrique Barboza1-2/+4
QEMU is failing to launch a CGS pSeries guest in a host that has PEF support: qemu-system-ppc64: ../softmmu/vl.c:2585: qemu_machine_creation_done: Assertion `machine->cgs->ready' failed. Aborted This is happening because we're not setting the cgs->ready flag that is asserted in qemu_machine_creation_done() during machine start. cgs->ready is set in s390_pv_kvm_init() and sev_kvm_init(). Let's set it in kvmppc_svm_init() as well. Reported-by: Ram Pai <linuxram@us.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210528201619.52363-1-danielhb413@gmail.com> Acked-by: Ram Pai <linuxram@us.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-06-03spapr: Set LPCR to current AIL mode when starting a new CPUNicholas Piggin1-5/+9
TCG does not keep track of AIL mode in a central place, it's based on the current LPCR[AIL] bits. Synchronize the new CPU's LPCR to the current LPCR in rtas_start_cpu(), similarly to the way the ILE bit is synchronized. Open-code the ILE setting as well now that the caller's LPCR is available directly, there is no need for the indirection. Without this, under both TCG and KVM, adding a POWER8/9/10 class CPU with a new core ID after a modern Linux has booted results in the new CPU's LPCR missing the LPCR[AIL]=0b11 setting that the other CPUs have. This can cause crashes and unexpected behaviour. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20210526091626.3388262-3-npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-06-03spapr: Remove stale comment about power-saving LPCR bitsNicholas Piggin1-1/+0
Commit 47a9b551547 ("spapr: Clean up handling of LPCR power-saving exit bits") moved this logic but did not remove the comment from the previous location. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20210526091626.3388262-2-npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-06-03spapr: nvdimm: Fix the persistent-memory root node name in device treeShivaprasad G Bhat1-2/+2
The FDT code is adding the pmem root node by name "persistent-memory" which should have been "ibm,persistent-memory". The linux fetches the device tree nodes by type and it has been working correctly as the type is correct. If someone searches by its intended name it would fail, so fix that. Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Message-Id: <162204278956.219.9061511386011411578.stgit@cc493db1e665> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-06-03spapr: nvdimm: Forward declare and move the definitionsShivaprasad G Bhat1-0/+12
The subsequent patches add definitions which tend to get the compilation to cyclic dependency. So, prepare with forward declarations, move the definitions and clean up. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Message-Id: <162133925415.610.11584121797866216417.stgit@4f1e6f2bd33e> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-06-03spapr: Fix EEH capability issue on KVM guest for PCI passthruMahesh Salgaonkar1-7/+33
With upstream kernel, especially after commit 98ba956f6a389 ("powerpc/pseries/eeh: Rework device EEH PE determination") we see that KVM guest isn't able to enable EEH option for PCI pass-through devices anymore. [root@atest-guest ~]# dmesg | grep EEH [ 0.032337] EEH: pSeries platform initialized [ 0.298207] EEH: No capable adapters found: recovery disabled. [root@atest-guest ~]# So far the linux kernel was assuming pe_config_addr equal to device's config_addr and using it to enable EEH on the PE through ibm,set-eeh-option RTAS call. Which wasn't the correct way as per PAPR. The linux kernel commit 98ba956f6a389 fixed this flow. With that fixed, linux now uses PE config address returned by ibm,get-config-addr-info2 RTAS call to enable EEH option per-PE basis instead of per-device basis. However this has uncovered a bug in qemu where ibm,set-eeh-option is treating PE config address as per-device config address. Hence in qemu guest with recent kernel the ibm,set-eeh-option RTAS call fails with -3 return value indicating that there is no PCI device exist for the specified PE config address. The rtas_ibm_set_eeh_option call uses pci_find_device() to get the PC device that matches specific bus and devfn extracted from PE config address passed as argument. Thus it tries to map the PE config address to a single specific PCI device 'bus->devices[devfn]' which always results into checking device on slot 0 'bus->devices[0]'. This succeeds when there is a pass-through device (vfio-pci) present on slot 0. But in cases where there is no pass-through device present in slot 0, but present in non-zero slots, ibm,set-eeh-option call fails to enable the EEH capability. hw/ppc/spapr_pci_vfio.c: spapr_phb_vfio_eeh_set_option() case RTAS_EEH_ENABLE: { PCIHostState *phb; PCIDevice *pdev; /* * The EEH functionality is enabled on basis of PCI device, * instead of PE. We need check the validity of the PCI * device address. */ phb = PCI_HOST_BRIDGE(sphb); pdev = pci_find_device(phb->bus, (addr >> 16) & 0xFF, (addr >> 8) & 0xFF); if (!pdev || !object_dynamic_cast(OBJECT(pdev), "vfio-pci")) { return RTAS_OUT_PARAM_ERROR; } hw/pci/pci.c:pci_find_device() PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn) { bus = pci_find_bus_nr(bus, bus_num); if (!bus) return NULL; return bus->devices[devfn]; } This patch fixes ibm,set-eeh-option to check for presence of any PCI device (vfio-pci) under specified bus and enable the EEH if found. The current code already makes sure that all the devices on that bus are from same iommu group (within same PE) and fail very early if it does not. After this fix guest is able to find EEH capable devices and enable EEH recovery on it. [root@atest-guest ~]# dmesg | grep EEH [ 0.048139] EEH: pSeries platform initialized [ 0.405115] EEH: Capable adapter found: recovery enabled. [root@atest-guest ~]# Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Message-Id: <162158429107.145117.5843504911924013125.stgit@jupiter> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-06-03spapr: Don't hijack current_machine->boot_orderGreg Kurz1-3/+5
QEMU 6.0 moved all the -boot variables to the machine. Especially, the removal of the boot_order static changed the handling of '-boot once' from: if (boot_once) { qemu_boot_set(boot_once, &error_fatal); qemu_register_reset(restore_boot_order, g_strdup(boot_order)); } to if (current_machine->boot_once) { qemu_boot_set(current_machine->boot_once, &error_fatal); qemu_register_reset(restore_boot_order, g_strdup(current_machine->boot_order)); } This means that we now register as subsequent boot order a copy of current_machine->boot_once that was just set with the previous call to qemu_boot_set(), i.e. we never transition away from the once boot order. It is certainly fragile^Wwrong for the spapr code to hijack a field of the base machine type object like that. The boot order rework simply turned this software boundary violation into an actual bug. Have the spapr code to handle that with its own field in SpaprMachineState. Also kfree() the initial boot device string when "once" was used. Fixes: 4b7acd2ac821 ("vl: clean up -boot variables") Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1960119 Cc: pbonzini@redhat.com Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20210521160735.1901914-1-groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-06-02docs: fix references to docs/devel/tracing.rstStefano Garzarella1-1/+1
Commit e50caf4a5c ("tracing: convert documentation to rST") converted docs/devel/tracing.txt to docs/devel/tracing.rst. We still have several references to the old file, so let's fix them with the following command: sed -i s/tracing.txt/tracing.rst/ $(git grep -l docs/devel/tracing.txt) Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210517151702.109066-2-sgarzare@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-05-26hw/mem/nvdimm: Use Kconfig 'imply' instead of 'depends on'Philippe Mathieu-Daudé1-0/+1
Per the kconfig.rst: A device should be listed [...] ``imply`` if (depending on the QEMU command line) the board may or may not be started without it. This is the case with the NVDIMM device, so use the 'imply' weak reverse dependency to select the symbol. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210511155354.3069141-2-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-19hw/ppc: moved has_spr to cpu.hLucas Mateus Castro (alqotel)3-12/+6
Moved has_spr to cpu.h as ppc_has_spr and turned it into an inline function. Change spr verification in pnv.c and spapr.c to a version that can compile in a !TCG environment. Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br> Message-Id: <20210507164146.67086-1-lucas.araujo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-19target/ppc: moved function out of mmu-hash64Lucas Mateus Castro (alqotel)1-0/+59
The function ppc_hash64_filter_pagesizes has been moved from a function with prototype in mmu-hash64.h and implemented in mmu-hash64.c to a static function in hw/ppc/spapr_caps.c as it's only used in that file. Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br> Message-Id: <20210506163941.106984-3-lucas.araujo@eldorado.org.br> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-19hw/ppc: moved hcalls that depend on softmmuLucas Mateus Castro (alqotel)3-576/+662
The hypercalls h_enter, h_remove, h_bulk_remove, h_protect, and h_read, have been moved to spapr_softmmu.c with the functions they depend on. The functions is_ram_address and push_sregs_to_kvm_pr are not static anymore as functions on both spapr_hcall.c and spapr_softmmu.c depend on them. The hypercalls h_resize_hpt_prepare and h_resize_hpt_commit have been divided, the KVM part stayed in spapr_hcall.c while the softmmu part was moved to spapr_softmmu.c Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br> Message-Id: <20210506163941.106984-2-lucas.araujo@eldorado.org.br> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-19hw/ppc/spapr.c: Make sure the host supports the selected MMU modeFabiano Rosas1-0/+1
Starting with Linux kernel v5.12 we dropped support[1] in KVM for hosts that can't have their threads running in different MMU modes (POWER9 < DD2.2). In these hosts, KVM will no longer report the KVM_CAP_PPC_MMU_HASH_V3 capability[2] when the host is running Radix. For guests that support both MMU modes, the negotiation during CAS will make sure it selects the correct one. For guests that only support Hash, such as P8 compat mode guests, the following error is currently thrown: $ ~/qemu-system-ppc64 -machine pseries,accel=kvm,max-cpu-compat=power8 ... error: kvm run failed Invalid argument NIP 0000000000000100 LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0 MSR 8000000000001000 HID0 0000000000000000 HF 8000000000000000 iidx 3 didx 3 TB 00000000 00000000 DECR 0 GPR00 0000000000000000 0000000000000000 0000000000000000 000000007ff00000 GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 CR 00000000 [ - - - - - - - - ] RES ffffffffffffffff SRR0 0000000000000000 SRR1 0000000000000000 PVR 00000000004e1201 VRSAVE 0000000000000000 SPRG0 0000000000000000 SPRG1 0000000000000000 SPRG2 0000000000000000 SPRG3 0000000000000000 SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000 HSRR0 0000000000000000 HSRR1 0000000000000000 CFAR 0000000000000000 LPCR 000000000004f01f PTCR 0000000000000000 DAR 0000000000000000 DSISR 0000000000000000 This patch adds a verification during the writing of the platform support vector so that we error out as soon as we determine this guest only supports Hash and the host doesn't. ~/qemu-system-ppc64 -machine pseries,accel=kvm,max-cpu-compat=power8 ... qemu-system-ppc64: Guest requested unavailable MMU mode (hash). 1- https://git.kernel.org/torvalds/p/b1b1697ae0cc8 2- https://git.kernel.org/torvalds/p/a722076e94702 Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Message-Id: <20210505001130.3999968-3-farosas@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-19hw/ppc/spapr.c: Extract MMU mode error reporting into a functionFabiano Rosas2-12/+18
A following patch will make use of it. Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Message-Id: <20210505001130.3999968-2-farosas@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-05Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.1-20210504' ↵Peter Maydell12-10/+246
into staging ppc patch queue 2021-05-04 Here's the first ppc pull request for qemu-6.1. It has a wide variety of stuff accumulated during the 6.0 freeze. Highlights are: * Multi-phase reset cleanups for PAPR * Preliminary cleanups towards allowing !CONFIG_TCG for the ppc target * Cleanup of AIL logic and extension to POWER10 * Further improvements to handling of hot unplug failures on PAPR * Allow much larger numbers of CPU on pseries * Support for the H_SCM_HEALTH hypercall * Add support for the Pegasos II board * Substantial cleanup to hflag handling * Assorted minor fixes and cleanups # gpg: Signature made Tue 04 May 2021 06:52:39 BST # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dg-gitlab/tags/ppc-for-6.1-20210504: (46 commits) hw/ppc/pnv_psi: Use device_cold_reset() instead of device_legacy_reset() hw/ppc/spapr_vio: Reset TCE table object with device_cold_reset() hw/intc/spapr_xive: Use device_cold_reset() instead of device_legacy_reset() target/ppc: removed VSCR from SPR registration target/ppc: Reduce the size of ppc_spr_t target/ppc: Clean up _spr_register et al target/ppc: Add POWER10 exception model target/ppc: rework AIL logic in interrupt delivery target/ppc: move opcode table logic to translate.c target/ppc: code motion from translate_init.c.inc to gdbstub.c spapr_drc.c: handle hotunplug errors in drc_unisolate_logical() spapr.h: increase FDT_MAX_SIZE spapr.c: do not use MachineClass::max_cpus to limit CPUs ppc: Rename current DAWR macros and variables target/ppc: POWER10 supports scv target/ppc: Fix POWER9 radix guest HV interrupt AIL behaviour docs/system: ppc: Add documentation for ppce500 machine roms/u-boot: Bump ppce500 u-boot to v2021.04 to fix broken pci support roms/Makefile: Update ppce500 u-boot build directory name ppc/spapr: Add support for implement support for H_SCM_HEALTH ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-05-04hw/ppc/pnv_psi: Use device_cold_reset() instead of device_legacy_reset()Peter Maydell1-2/+2
The pnv_psi.c code uses device_legacy_reset() for two purposes: * to reset itself from its qemu_register_reset() handler * to reset a XiveSource object it has Neither it nor the XiveSource have any qbuses, so the new device_cold_reset() function (which resets both the device and its child buses) is equivalent here to device_legacy_reset() and we can just switch to the new API. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210503151849.8766-4-peter.maydell@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04hw/ppc/spapr_vio: Reset TCE table object with device_cold_reset()Peter Maydell1-1/+1
The spapr_vio_quiesce_one() function resets the TCE table object (TYPE_SPAPR_TCE_TABLE) via device_legacy_reset(). We know that objects of that type do not have a qbus of their own, so the new device_cold_reset() function (which resets both the device and its child buses) is equivalent here to device_legacy_reset() and we can just switch to the new API. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210503151849.8766-3-peter.maydell@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04target/ppc: Add POWER10 exception modelNicholas Piggin1-1/+6
POWER10 adds a new bit that modifies interrupt behaviour, LPCR[HAIL], and it removes support for the LPCR[AIL]=0b10 mode. Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20210501072436.145444-3-npiggin@gmail.com> [dwg: Corrected tab indenting] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04target/ppc: rework AIL logic in interrupt deliveryNicholas Piggin1-1/+2
The AIL logic is becoming unmanageable spread all over powerpc_excp(), and it is slated to get even worse with POWER10 support. Move it all to a new helper function. Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20210501072436.145444-2-npiggin@gmail.com> [dwg: Corrected tab indenting] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04spapr_drc.c: handle hotunplug errors in drc_unisolate_logical()Daniel Henrique Barboza1-0/+23
At this moment, PAPR does not provide a way to report errors during a device removal operation. This led the pSeries machine to implement extra mechanisms to try to fallback and recover from an error that might have happened during the hotunplug in the guest side. This started to change a bit with commit fe1831eff8a4 ("spapr_drc.c: use DRC reconfiguration to cleanup DIMM unplug state"), where one way to fallback from a memory removal error was introduced. Around the same time, in [1], the idea of using RTAS set-indicator for this role was first introduced. The RTAS set-indicator call, when attempting to UNISOLATE a DRC that is already UNISOLATED or CONFIGURED, returns RTAS_OK and does nothing else for both QEMU and phyp. This gives us an opportunity to use this behavior to signal the hypervisor layer when a device removal errir happens, allowing QEMU/phyp to do a proper error handling. Using set-indicator to report HP errors isn't strange to PAPR, as per R1-13.5.3.4-4. of table 13.7 of current PAPR [2]: "For all DR options: If this is a DR operation that involves the user insert- ing a DR entity, then if the firmware can determine that the inserted entity would cause a system disturbance, then the set-indicator RTAS call must not unisolate the entity and must return an error status which is unique to the particular error." A change was proposed to the pSeries Linux kernel to call set-indicator to move a DRC to 'unisolate' in the case of a hotunplug error in the guest side [3]. Setting a DRC that is already unisolated or configured to 'unisolate' is a no-op (returns RTAS_OK) for QEMU and also for phyp. Being a benign change for hypervisors that doesn't care about handling such errors, we expect the kernel to accept this change at some point. This patch prepares the pSeries machine for this new kernel feature by changing drc_unisolate_logical() to handle guest side hotunplug errors. For CPUs it's a simple matter of setting drc->unplug_requested to 'false', while for LMBs the process is similar to the rollback that is done in rtas_ibm_configure_connector(). [1] https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg06395.html [2] https://openpowerfoundation.org/wp-content/uploads/2020/07/LoPAR-20200611.pdf [3] https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210416210216.380291-3-danielhb413@gmail.com/ Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210420165100.108368-2-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04spapr.c: do not use MachineClass::max_cpus to limit CPUsDaniel Henrique Barboza1-1/+10
Up to this patch, 'max_cpus' value is hardcoded to 1024 (commit 6244bb7e5811). In theory this patch would simply bump it to 2048, since it's the default NR_CPUS kernel setting for ppc64 servers nowadays, but the whole mechanic of MachineClass:max_cpus is flawed for the pSeries machine. The two supported accelerators, KVM and TCG, can live without it. TCG guests don't have a theoretical limit. The user must be free to emulate as many CPUs as the hardware is capable of. And even if there were a limit, max_cpus is not the proper way to report it since it's a common value checked by SMP code in machine_smp_parse() for KVM as well. For KVM guests, the proper way to limit KVM CPUs is by host configuration via NR_CPUS, not a QEMU hardcoded value. There is no technical reason for a pSeries QEMU guest to forcefully stay below NR_CPUS. This hardcoded value also disregard hosts that might have a lower NR_CPUS limit, say 512. In this case, machine.c:machine_smp_parse() will allow a 1024 value to pass, but then kvm_init() will complain about it because it will exceed NR_CPUS: Number of SMP cpus requested (1024) exceeds the maximum cpus supported by KVM (512) A better 'max_cpus' value would consider host settings, but MachineClass::max_cpus is defined well before machine_init() and kvm_init(). We can't check for KVM limits because it's too soon, so we end up making a guess. This patch makes MachineClass:max_cpus settings innocuous by setting it to INT32_MAX. machine.c:machine_smp_parse() will not fail the verification based on max_cpus, letting kvm_init() do the checking with actual host settings. And TCG guests get to do whatever the hardware is capable of emulating. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210408204049.221802-2-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04ppc/spapr: Add support for implement support for H_SCM_HEALTHVaibhav Jain1-0/+36
Add support for H_SCM_HEALTH hcall described at [1] for spapr nvdimms. This enables guest to detect the 'unarmed' status of a specific spapr nvdimm identified by its DRC and if its unarmed, mark the region backed by the nvdimm as read-only. The patch adds h_scm_health() to handle the H_SCM_HEALTH hcall which returns two 64-bit bitmaps (health bitmap, health bitmap mask) derived from 'struct nvdimm->unarmed' member. Linux kernel side changes to enable handling of 'unarmed' nvdimms for ppc64 are proposed at [2]. References: [1] "Hypercall Op-codes (hcalls)" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/powerpc/papr_hcalls.rst#n220 [2] "powerpc/papr_scm: Mark nvdimm as unarmed if needed during probe" https://lore.kernel.org/linux-nvdimm/20210329113103.476760-1-vaibhav@linux.ibm.com/ Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Message-Id: <20210402102128.213943-1-vaibhav@linux.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04spapr: Rename RTAS_MAX_ADDR to FDT_MAX_ADDRAlexey Kardashevskiy1-4/+4
SLOF instantiates RTAS since 744a928ccee9 ("spapr: Stop providing RTAS blob") so the max address applies to the FDT only. This renames the macro and fixes up the comment. This should not cause any behavioral change. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20210331025123.29310-1-aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04hw/ppc: Add emulation of Genesi/bPlan Pegasos IIBALATON Zoltan3-0/+155
Add new machine called pegasos2 emulating the Genesi/bPlan Pegasos II, a PowerPC board based on the Marvell MV64361 system controller and the VIA VT8231 integrated south bridge/superio chips. It can run Linux, AmigaOS and a wide range of MorphOS versions. Currently a firmware ROM image is needed to boot and only MorphOS has a video driver to produce graphics output. Linux could work too but distros that supported this machine don't include usual video drivers so those only run with serial console for now. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <30cbfb9cbe6f46a1e15a69a75fac45ac39340122.1616680239.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04hw/ppc/spapr_rtas: Update hflags after setting msrRichard Henderson1-0/+2
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210315184615.1985590-16-richard.henderson@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04hw/ppc/pnv_core: Update hflags after setting msrRichard Henderson1-1/+2
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210315184615.1985590-15-richard.henderson@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-04hw/ppc/mac_newworld: Restrict RAM to 2 GiBPhilippe Mathieu-Daudé1-0/+4
On Mac99 and newer machines, the Uninorth PCI host bridge maps the PCI hole region at 2GiB, so the RAM area beside 2GiB is not accessible by the CPU. Restrict the memory to 2GiB to avoid problems such the one reported in the buglink. Buglink: https://bugs.launchpad.net/qemu/+bug/1922391 Reported-by: Håvard Eidnes <he@NetBSD.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210406084842.2859664-1-f4bug@amsat.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-05-02Do not include exec/address-spaces.h if it's not really necessaryThomas Huth16-16/+0
Stop including exec/address-spaces.h in files that don't need it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-5-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-02Do not include cpu.h if it's not really necessaryThomas Huth13-13/+0
Stop including cpu.h in files that don't need it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-4-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-02Do not include hw/boards.h if it's not really necessaryThomas Huth8-8/+0
Stop including hw/boards.h in files that don't need it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-3-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-02Do not include sysemu/sysemu.h if it's not really necessaryThomas Huth2-2/+0
Stop including sysemu/sysemu.h in files that don't need it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-2-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-02hw: Do not include qemu/log.h if it is not necessaryThomas Huth6-6/+0
Many files include qemu/log.h without needing it. Remove the superfluous include statements. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20210328054833.2351597-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-02hw: Do not include hw/irq.h if it is not necessaryThomas Huth1-1/+0
Many files include hw/irq.h without needing it. Remove the superfluous include statements. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20210327050236.2232347-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-04-30hw: add compat machines for 6.1Cornelia Huck1-2/+13
Add 6.1 machine types for arm/i440fx/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Greg Kurz <groug@kaod.org> Message-id: 20210331111900.118274-1-cohuck@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>