aboutsummaryrefslogtreecommitdiff
path: root/hw/pci-host
AgeCommit message (Collapse)AuthorFilesLines
2023-02-05ppc/pnv/pci: Fix PHB xscom registers memory region nameFrederic Barrat1-1/+1
The name is for the region mapping the PHB xscom registers. It was apparently a bad cut-and-paste from the per-stack pci xscom area just above, so we had two regions with the same name. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20230127122848.550083-5-fbarrat@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-02-05hw/pci-host/mv64361: Reuse pci_swizzle_map_irq_fnBernhard Beschow1-6/+1
mv64361_pcihost_map_irq() is a reimplementation of pci_swizzle_map_irq_fn(). Resolve this redundancy. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20230106113927.8603-1-shentey@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-01-27hw/pci-host: Use register definitions from PCI standardPhilippe Mathieu-Daudé3-26/+15
No need to document magic values when the definition names from "standard-headers/linux/pci_regs.h" are self-explicit. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230105173702.56610-1-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bernhard Beschow <shentey@gmail.com>
2023-01-20Merge tag 'pull-include-2023-01-20' of https://repo.or.cz/qemu/armbru into ↵Peter Maydell3-1/+3
staging Header cleanup patches for 2023-01-20 # -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEENUvIs9frKmtoZ05fOHC0AOuRhlMFAmPKN6YSHGFybWJydUBy # ZWRoYXQuY29tAAoJEDhwtADrkYZTPeoQAIKl/BF6PFRNq0/k3vPqMe6nltjgkpa/ # p7E5qRlo31RCeUB+f0iW26mySnNTgYkE28yy57HxUML/9Lp1bbxyDgRNiJ406a4L # kFVF04kOIFez1+mfvWN92DZqcl/EAAqNL6XqSFyO38kYwcsFsi+BZ7DLZbL9Ea8v # wVywB96mN6KyrLWCJ2D0OqIVuPHSHol+5zt9e6+ShBgN0FfElLbv0F4KH3VJ1olA # psKl6w6V9+c2zV1kT/H+S763m6mQdwtVo/UuOJoElI+Qib/UBxDOrhdYf4Zg7hKf # ByUuhJUASm8y9yD/42mFs90B6eUNzLSBC8v1PgRqSqDHtllveP4RysklBlyIMlOs # DKtqEuRuIJ/qDXliIFHY6tBnUkeITSd7BCxkQYfaGyaSOcviDSlE3AyaaBC0sY4F # P/lTTiRg5ksvhDYtJnW3mSfmT2PY7aBtyE3D1Z84v9hek6D0reMQTE97yL/j4m7P # wJP8aM3Z8GILCVxFIh02wmqWZhZUCGsIDS/vxVm+u060n66qtDIQFBoazsFJrCME # eWI+qDNDr6xhLegeYajGDM9pdpQc3x0siiuHso4wMSI9NZxwP+tkCVhTpqmrRcs4 # GSH/4IlUXqEZdUQDL38DfA22C1TV8BzyMhGLTUERWWYki1sr99yv0pdFyk5r3nLB # SURwr58rB2zo # =dOfq # -----END PGP SIGNATURE----- # gpg: Signature made Fri 20 Jan 2023 06:41:42 GMT # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * tag 'pull-include-2023-01-20' of https://repo.or.cz/qemu/armbru: include/hw/ppc include/hw/pci-host: Drop extra typedefs include/hw/ppc: Don't include hw/pci-host/pnv_phb.h from pnv.h include/hw/ppc: Supply a few missing includes include/hw/ppc: Split pnv_chip.h off pnv.h include/hw/block: Include hw/block/block.h where needed hw/sparc64/niagara: Use blk_name() instead of open-coding it include/block: Untangle inclusion loops coroutine: Use Coroutine typedef name instead of structure tag coroutine: Split qemu/coroutine-core.h off qemu/coroutine.h coroutine: Clean up superfluous inclusion of qemu/lockable.h coroutine: Move coroutine_fn to qemu/osdep.h, trim includes coroutine: Clean up superfluous inclusion of qemu/coroutine.h Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2023-01-20include/hw/ppc include/hw/pci-host: Drop extra typedefsMarkus Armbruster1-1/+1
PnvChip is typedef'ed in five places, and PnvPhb4PecState in two. Keep one, drop the others. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20221222104628.659681-5-armbru@redhat.com>
2023-01-20include/hw/ppc: Split pnv_chip.h off pnv.hMarkus Armbruster2-0/+2
PnvChipClass, PnvChip, Pnv8Chip, Pnv9Chip, and Pnv10Chip are defined in pnv.h. Many users of the header don't actually need them. One instance is this inclusion loop: hw/ppc/pnv_homer.h includes hw/ppc/pnv.h for typedef PnvChip, and vice versa for struct PnvHomer. Similar structs live in their own headers: PnvHomerClass and PnvHomer in pnv_homer.h, PnvLpcClass and PnvLpcController in pci_lpc.h, PnvPsiClass, PnvPsi, Pnv8Psi, Pnv9Psi, Pnv10Psi in pnv_psi.h, ... Move PnvChipClass, PnvChip, Pnv8Chip, Pnv9Chip, and Pnv10Chip to new pnv_chip.h, and adjust include directives. This breaks the inclusion loop mentioned above. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20221222104628.659681-2-armbru@redhat.com>
2023-01-19Merge tag 'trivial-branch-for-8.0-pull-request' of ↵Peter Maydell2-4/+2
https://gitlab.com/laurent_vivier/qemu into staging trivial branch pull request 20230118 # -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEEzS913cjjpNwuT1Fz8ww4vT8vvjwFAmPHpRASHGxhdXJlbnRA # dml2aWVyLmV1AAoJEPMMOL0/L748fwEP+wTA6dBYqRnZMCPEkk6yy0nSVr6GF8FA # i9JrUbRuBf8WT2RAFJEwOyACTaYgCwqU9tu6UxG2ekGfGDtR84HH1yozTAbBuPct # qoT/cvrQ0/Nfymw1Ia1vH5D6EQiAn+j6/1C41PEHvqTQBMe8E4U8jDIwbXTaJS7j # QSUDplRfCbSBXQ9ctFrcD6XxX06dj4U9l8L4gl5Uc4B1OmFacyJnfzMIyVRTIhvF # S4sKB/8B36emFITw/gk+MW5HnBgjEIWvZjof71eglMqo79jmacGeOe8NQi1+ApQ1 # lVmllKewdgLHVwdOGVX4dCJQdhSL/7DjreqtKGrUmhZfJdmCWJdl3jVWqhr4lfME # U7ytd68iLdKgfKqepc3+WbhA8pWT+brPVpTU9hq17DsNJqeZa6628OguDEtjz9dP # 4Y4XFZMxFadYl4YaCpGzTN1tqsrO8Ct+Kvq/90nt5FUeTX+i+/WM/9XXNf9MD4VS # OVCwHXCa4yHMMq2LGV0sWaL7vSI26lv0asKtalAelbVZhVyB1kSZfde2rZXuhoD5 # S2d9x2bcFG6WNlDfyaANkCKyHlxUaOroQVE+y0SqgtaC2oPhuXtG6fusiyvjG9+l # 9O6jy87e4uR+Xach6MmybMjiPDi0VMvPayVz3BR/6hBZZB/GkLO1OmNQcZiXcbOd # yROzKPmyZ/q+ # =35x0 # -----END PGP SIGNATURE----- # gpg: Signature made Wed 18 Jan 2023 07:51:44 GMT # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * tag 'trivial-branch-for-8.0-pull-request' of https://gitlab.com/laurent_vivier/qemu: hw/ssi/sifive_spi.c: spelling: reigster hw/cxl/cxl-host: Fix an error message typo hw/cxl/cxl-cdat.c: spelling: missmatch hw/pvrdma: Protect against buggy or malicious guest driver ccid-card-emulated: fix cast warning/error hw/i386/pc: Remove unused 'owner' argument from pc_pci_as_mapping_init tests/qtest/test-hmp: Improve the check for verbose mode hw/usb: Mark the XLNX_VERSAL-related files as target-independent hw/intc: Mark more interrupt-controller files as target independent hw/cpu: Mark arm11 and realview mpcore as target-independent code hw/arm: Move various units to softmmu_ss[] hw/tpm: Move tpm_ppi.c out of target-specific source set hw/intc: Move some files out of the target-specific source set hw/display: Move omap_lcdc.c out of target-specific source set Call qemu_socketpair() instead of socketpair() when possible Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2023-01-18bulk: Rename TARGET_FMT_plx -> HWADDR_FMT_plxPhilippe Mathieu-Daudé2-9/+9
The 'hwaddr' type is defined in "exec/hwaddr.h" as: hwaddr is the type of a physical address (its size can be different from 'target_ulong'). All definitions use the 'HWADDR_' prefix, except TARGET_FMT_plx: $ fgrep define include/exec/hwaddr.h #define HWADDR_H #define HWADDR_BITS 64 #define HWADDR_MAX UINT64_MAX #define TARGET_FMT_plx "%016" PRIx64 ^^^^^^ #define HWADDR_PRId PRId64 #define HWADDR_PRIi PRIi64 #define HWADDR_PRIo PRIo64 #define HWADDR_PRIu PRIu64 #define HWADDR_PRIx PRIx64 #define HWADDR_PRIX PRIX64 Since hwaddr's size can be *different* from target_ulong, it is very confusing to read one of its format using the 'TARGET_FMT_' prefix, normally used for the target_long / target_ulong types: $ fgrep TARGET_FMT_ include/exec/cpu-defs.h #define TARGET_FMT_lx "%08x" #define TARGET_FMT_ld "%d" #define TARGET_FMT_lu "%u" #define TARGET_FMT_lx "%016" PRIx64 #define TARGET_FMT_ld "%" PRId64 #define TARGET_FMT_lu "%" PRIu64 Apparently this format was missed during commit a8170e5e97 ("Rename target_phys_addr_t to hwaddr"), so complete it by doing a bulk-rename with: $ sed -i -e s/TARGET_FMT_plx/HWADDR_FMT_plx/g $(git grep -l TARGET_FMT_plx) Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230110212947.34557-1-philmd@linaro.org> [thuth: Fix some warnings from checkpatch.pl along the way] Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-01-16hw/i386/pc: Remove unused 'owner' argument from pc_pci_as_mapping_initPhilippe Mathieu-Daudé2-4/+2
This argument was added 9 years ago in commit 83d08f2673 ("pc: map PCI address space as catchall region for not mapped addresses") and has never been used since, so remove it. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20230105173826.56748-1-philmd@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2023-01-13hw/pci-host/bonito: Declare TYPE_BONITO_PCI_HOST_BRIDGE in headerPhilippe Mathieu-Daudé1-3/+1
Declare the TYPE_BONITO_PCI_HOST_BRIDGE QOM type in a header to be able to access it from board code. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230105130710.49264-8-philmd@linaro.org>
2023-01-13hw/pci-host/bonito: Use 'bonito_pci' for PCI function #0 codePhilippe Mathieu-Daudé1-6/+6
To make it easier to differentiate between the Host Bridge object and its PCI function #0, rename bonito* as bonito_pci*. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230105130710.49264-4-philmd@linaro.org>
2023-01-13hw/pci-host/bonito: Use 'bonito_host' for PCI host bridge codePhilippe Mathieu-Daudé1-6/+6
To make it easier to differentiate between the Host Bridge object and its PCI function #0, rename bonito_pcihost* as bonito_host*. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230105130710.49264-3-philmd@linaro.org>
2023-01-13hw/pci-host/bonito: Convert to 3-phase resetPhilippe Mathieu-Daudé1-5/+4
Convert the TYPE_PCI_BONITO class to use 3-phase reset. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230105130710.49264-2-philmd@linaro.org>
2023-01-13hw/pci/pci: Factor out pci_bus_map_irqs() from pci_bus_irqs()Bernhard Beschow2-2/+4
pci_bus_irqs() coupled together the assignment of pci_set_irq_fn and pci_map_irq_fn to a PCI bus. This coupling gets in the way when the pci_map_irq_fn is board-specific while the pci_set_irq_fn is device- specific. For example, both of QEMU's PIIX south bridge models have different pci_map_irq_fn implementations which are board-specific rather than device-specific. These implementations should therefore reside in board code. The pci_set_irq_fn's, however, should stay in the device models because they access memory internal to the model. Factoring out pci_bus_map_irqs() from pci_bus_irqs() allows the assignments to be decoupled, resolving the problem described above. Note also how pci_vpb_realize() which gets touched in this commit assigns different pci_map_irq_fn's depending on the board. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230109172347.1830-5-shentey@gmail.com> [PMD: Factor out in vfu_object_set_bus_irq()] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-01-13hw/mips/gt64xxx_pci: Move it to hw/pci-host/Philippe Mathieu-Daudé4-0/+1308
The GT-64120 is a north-bridge, and it is not MIPS specific. Move it with the other north-bridge devices. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20221209151533.69516-8-philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2023-01-08include/hw/pci: Split pci_device.h off pci.hMarkus Armbruster9-9/+9
PCIDeviceClass and PCIDevice are defined in pci.h. Many users of the header don't actually need them. Similar structs live in their own headers: PCIBusClass and PCIBus in pci_bus.h, PCIBridge in pci_bridge.h, PCIHostBridgeClass and PCIHostState in pci_host.h, PCIExpressHost in pcie_host.h, and PCIERootPortClass, PCIEPort, and PCIESlot in pcie_port.h. Move PCIDeviceClass and PCIDeviceClass to new pci_device.h, along with the code that needs them. Adjust include directives. This also enables the next commit. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20221222100330.380143-6-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21pci: drop redundant PCIDeviceClass::is_bridge fieldIgor Mammedov2-2/+0
and use cast to TYPE_PCI_BRIDGE instead. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20221129101341.185621-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
2022-12-21remove DEC 21154 PCI bridgeIgor Mammedov1-5/+4
Code has not been used practically since its inception (2004) f2aa58c6f4a20 UniNorth PCI bridge support or maybe even earlier, but it was consuming contributors time as QEMU was being rewritten. Drop it for now. Whomever would like to actually use the thing, can make sure it actually works/reintroduce it back when there is a user. PS: I've stumbled upon this when replacing PCIDeviceClass::is_bridge field with QOM cast to PCI_BRIDGE type. Unused DEC 21154 was the only one trying to use the field with plain PCIDevice. It's not worth keeping the field around for the sake of the code that was commented out 'forever'. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20221129101341.185621-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-16hw/pci-host/pnv_phb3_msi: Convert TYPE_PHB3_MSI to 3-phase resetPeter Maydell1-6/+9
Convert the TYPE_PHB3_MSI class to 3-phase reset, so we can avoid using the device_class_set_parent_reset() function. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20221125115240.3005559-8-peter.maydell@linaro.org
2022-12-16hw/intc/xics: Reset TYPE_ICS objects with device_cold_reset()Peter Maydell1-7/+0
The realize method for the TYPE_ICS class uses qemu_register_reset() to register a reset handler, as a workaround for the fact that currently objects which directly inherit from TYPE_DEVICE don't get automatically reset. However, the reset function directly calls ics_reset(), which is the function that implements the legacy reset method. This means that only the parent class's data gets reset, and a subclass which also needs to handle reset, like TYPE_PHB3_MSI, has to register its own reset function. Make the TYPE_ICS reset function call device_cold_reset() instead: this will handle reset for both the parent class and the subclass, and will work whether the classes are using legacy reset or 3-phase reset. This allows us to remove the reset function that the subclass currently has to set up. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20221125115240.3005559-6-peter.maydell@linaro.org
2022-12-16pci: Convert child classes of TYPE_PCIE_ROOT_PORT to 3-phase resetPeter Maydell1-8/+10
Convert the TYPE_CXL_ROOT_PORT and TYPE_PNV_PHB_ROOT_PORT classes to 3-phase reset, so they don't need to use the deprecated device_class_set_parent_reset() function any more. We have to do both in the same commit, because they keep the parent_reset field in their common parent class's class struct. Note that pnv_phb_root_port_class_init() was pointlessly setting dc->reset twice, once by calling device_class_set_parent_reset() and once directly. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20221125115240.3005559-5-peter.maydell@linaro.org
2022-11-10hw/pci-host/pnv_phb: Avoid quitting QEMU if hotplug of pnv-phb-root-port failsThomas Huth1-2/+10
Currently QEMU terminates if you try to hotplug pnv-phb-root-port in an environment where it is not supported, e.g. if doing this: echo "device_add pnv-phb-root-port" | \ ./qemu-system-ppc64 -monitor stdio -M powernv9 To avoid this problem, the pnv_phb_root_port_realize() function should not use error_fatal when trying to set the properties which might not be available. Fixes: c2f3f78af5 ("ppc/pnv: set root port chassis and slot using Bus properties") Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20221109122210.115667-1-thuth@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-31hw/ppc/mac.h: Rename to include/hw/nvram/mac_nvram.hBALATON Zoltan2-2/+0
All that is left in mac.h now belongs to the nvram emulation so rename it accordingly and only include it where it is really used. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <b82449369f718c0e207fe8c332fab550fa0230c0.1666957578.git.balaton@eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2022-10-31hw/ppc/mac.h: Move grackle-pcihost type declaration out to a headerBALATON Zoltan1-13/+1
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <b133a84dfd38366eea2bb11b7ca433758efacc10.1666957578.git.balaton@eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2022-09-20hw/pci-host: pnv_phb{3, 4}: Fix heap out-of-bound access failureXuzhou Cheng2-0/+2
pnv_phb3_root_bus_info and pnv_phb4_root_bus_info are missing the instance_size initialization. This results in accessing out-of-bound memory when setting 'chip-id' and 'phb-id', and eventually crashes glib's malloc functionality with the following message: "qemu-system-ppc64: GLib: ../glib-2.72.3/glib/gmem.c:131: failed to allocate 3232 bytes" This issue was noticed only when running qtests with QEMU Windows 32-bit executable. Windows 64-bit, Linux 32/64-bit do not expose this bug though. Fixes: 9ae1329ee2fe ("ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridge") Fixes: 4f9924c4d4cf ("ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridge") Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Xuzhou Cheng <xuzhou.cheng@windriver.com> Signed-off-by: Bin Meng <bin.meng@windriver.com> Message-Id: <20220920103159.1865256-29-bmeng.cn@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/pnv: fix QOM parenting of user creatable root portsDaniel Henrique Barboza1-27/+20
User creatable root ports are being parented by the 'peripheral' or the 'peripheral-anon' container. This happens because this is the regular QOM schema for sysbus devices that are added via the command line. Let's make this QOM hierarchy similar to what we have with default root ports, i.e. the root port must be parented by the pnv-root-bus. To do that we change the qom and bus parent of the root port during root_port_realize(). The realize() is shared by the default root port code path, so we can remove the code inside pnv_phb_attach_root_port() that was adding the root port as a child of the bus as well. After all that, remove pnv_phb_attach_root_port() and create the root port explictly in the 'default_enabled()' case of pnv_phb_realize(). Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220819094748.400578-3-danielhb413@gmail.com>
2022-08-31ppc/pnv: consolidate pnv_parent_*_fixup() helpersDaniel Henrique Barboza1-15/+28
We have 2 helpers that amends the QOM and parent bus of a given object, repectively. These 2 helpers are called together, and not by accident. Due to QOM internals, doing an object_unparent() will result in the device being removed from its parent bus. This means that changing the QOM parent requires reassigning the parent bus again. Create a single helper called pnv_parent_fixup(), documenting some of the QOM specifics that we're dealing with the unparenting/parenting mechanics, and handle both the QOM and the parent bus assignment. Next patch will make use of this function to handle a case where we need to change the QOM parent while keeping the same parent bus assigned beforehand. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220819094748.400578-2-danielhb413@gmail.com>
2022-08-31ppc/pnv: enable user created pnv-phb for powernv9Daniel Henrique Barboza2-3/+5
Enable pnv-phb user created devices for powernv9 now that we have everything in place. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-9-danielhb413@gmail.com>
2022-08-31ppc/pnv: enable user created pnv-phb for powernv8Daniel Henrique Barboza1-2/+7
The bulk of the work was already done by previous patches. Use defaults_enabled() to determine whether we need to create the default devices or not. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-7-danielhb413@gmail.com>
2022-08-31ppc/pnv: add helpers for pnv-phb user devicesDaniel Henrique Barboza1-0/+75
pnv_parent_qom_fixup() and pnv_parent_bus_fixup() are versions of the helpers that were reverted by commit 9c10d86fee "ppc/pnv: Remove user-created PHB{3,4,5} devices". They are needed to amend the QOM and bus hierarchies of user created pnv-phbs, matching them with default pnv-phbs. A new helper pnv_phb_user_device_init() is created to handle user-created devices setup. We're going to call it inside pnv_phb_realize() in case we're realizing an user created device. This will centralize all user device realated in a single spot, leaving the realize functions of the phb3/phb4 backends untouched. Another helper called pnv_chip_add_phb() was added to handle the particularities of each chip version when adding a new PHB. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-5-danielhb413@gmail.com>
2022-08-31ppc/pnv: set root port chassis and slot using Bus propertiesDaniel Henrique Barboza1-9/+16
For default root ports we have a way of accessing chassis and slot, before root_port_realize(), via pnv_phb_attach_root_port(). For the future user created root ports this won't be the case: we can't use this helper because we don't have access to the PHB phb-id/chip-id values. In earlier patches we've added phb-id and chip-id to pnv-phb-root-bus objects. We're now able to use the bus to retrieve them. The bus is reachable for both user created and default devices, so we're changing all the code paths. This also allow us to validate these changes with the existing default devices. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-4-danielhb413@gmail.com>
2022-08-31ppc/pnv: add phb-id/chip-id PnvPHB4RootBus propertiesDaniel Henrique Barboza1-0/+51
The same rationale provided in the PHB3 bus case applies here. Note: we could have merged both buses in a single object, like we did with the root ports, and spare some boilerplate. The reason we opted to preserve both buses objects is twofold: - there's not user side advantage in doing so. Unifying the root ports presents a clear user QOL change when we enable user created devices back. The buses objects, aside from having a different QOM name, is transparent to the user; - we leave a door opened in case we want to increase the root port limit for phb4/5 later on without having to deal with phb3 code. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-3-danielhb413@gmail.com>
2022-08-31ppc/pnv: add phb-id/chip-id PnvPHB3RootBus propertiesDaniel Henrique Barboza1-0/+50
We rely on the phb-id and chip-id, which are PHB properties, to assign chassis and slot to the root port. For default devices this is no big deal: the root port is being created under pnv_phb_realize() and the values are being passed on via the 'index' and 'chip-id' of the pnv_phb_attach_root_port() helper. If we want to implement user created root ports we have a problem. The user created root port will not be aware of which PHB it belongs to, unless we're willing to violate QOM best practices and access the PHB via dev->parent_bus->parent. What we can do is to access the root bus parent bus. Since we're already assigning the root port as QOM child of the bus, and the bus is initiated using PHB properties, let's add phb-id and chip-id as properties of the bus. This will allow us trivial access to them, for both user-created and default root ports, without doing anything too shady with QOM. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-2-danielhb413@gmail.com>
2022-08-31ppc/pnv: move attach_root_port helper to pnv-phb.cDaniel Henrique Barboza1-0/+24
The helper is only used in this file. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-13-danielhb413@gmail.com>
2022-08-31ppc/pnv: remove pecc->rp_modelDaniel Henrique Barboza1-2/+0
The attribute is unused. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-11-danielhb413@gmail.com>
2022-08-31ppc/pnv: remove root port name from pnv_phb_attach_root_port()Daniel Henrique Barboza1-6/+1
We support only a single root port, PNV_PHB_ROOT_PORT. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-10-danielhb413@gmail.com>
2022-08-31ppc/pnv: remove pnv-phb4-root-portDaniel Henrique Barboza3-89/+4
The unified pnv-phb-root-port can be used instead. The phb4-root-port device isn't exposed to the user in any official QEMU release so there's no ABI breakage in removing it. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-9-danielhb413@gmail.com>
2022-08-31ppc/pnv: remove pnv-phb3-root-portDaniel Henrique Barboza2-43/+1
The unified pnv-phb-root-port can be used in its place. There is no ABI breakage in doing so because no official QEMU release introduced user creatable pnv-phb3-root-port devices. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-8-danielhb413@gmail.com>
2022-08-31ppc/pnv: add pnv-phb-root-port deviceDaniel Henrique Barboza2-8/+123
We have two very similar root-port devices, pnv-phb3-root-port and pnv-phb4-root-port. Both consist of a wrapper around the PCIESlot device that, until now, has no additional attributes. The main difference between the PHB3 and PHB4 root ports is that pnv-phb4-root-port has the pnv_phb4_root_port_reset() callback. All other differences can be merged in a single device without too much trouble. This patch introduces the unified pnv-phb-root-port that, in time, will be used as the default root port for the pnv-phb device. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-7-danielhb413@gmail.com>
2022-08-31ppc/pnv: turn PnvPHB4 into a PnvPHB backendDaniel Henrique Barboza2-27/+6
Change the parent type of the PnvPHB4 device to TYPE_PARENT since the PCI bus is going to be initialized by the PnvPHB parent. Functions that needs to access the bus via a PnvPHB4 object can do so via the phb4->phb_base pointer. pnv_phb4_pec now creates a PnvPHB object. The powernv9 machine class will create PnvPHB devices with version '4'. powernv10 will create using version '5'. Both are using global machine properties in their class_init() to do that. These changes will benefit us when adding PnvPHB user creatable devices for powernv9 and powernv10. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-6-danielhb413@gmail.com>
2022-08-31ppc/pnv: add PHB4 bus init helperDaniel Henrique Barboza2-16/+25
Similar to what we already did for the PnvPHB3 device, let's add a helper to init the bus when using a PnvPHB4. This helper will be used by PnvPHb when PnvPHB4 turns into a backend. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-5-danielhb413@gmail.com>
2022-08-31ppc/pnv: turn PnvPHB3 into a PnvPHB backendDaniel Henrique Barboza1-22/+5
We need a handful of changes that needs to be done in a single swoop to turn PnvPHB3 into a PnvPHB backend. In the PnvPHB3, since the PnvPHB device implements PCIExpressHost and will hold the PCI bus, change PnvPHB3 parent to TYPE_DEVICE. There are a couple of instances in pnv_phb3.c that needs to access the PCI bus, so a phb_base pointer is added to allow access to the parent PnvPHB. The PnvPHB3 root port will now be connected to a PnvPHB object. In pnv.c, the powernv8 machine chip8 will now hold an array of PnvPHB objects. pnv_get_phb3_child() needs to be adapted to return the PnvPHB3 backend from the PnvPHB child. A global property is added in pnv_machine_power8_class_init() to ensure that all PnvPHBs are created with phb->version = 3. After all these changes we're still able to boot a powernv8 machine with default settings. The real gain will come with user created PnvPHB devices, coming up next. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-4-danielhb413@gmail.com>
2022-08-31ppc/pnv: add PnvPHB base/proxy deviceDaniel Henrique Barboza3-1/+165
The PnvPHB device is going to be the base device for all other powernv PHBs. It consists of a device that has the same user API as the other PHB, namely being a PCIHostBridge and having chip-id and index properties. It also has a 'backend' pointer that will be initialized with the PHB implementation that the device is going to use. The initialization of the PHB backend is done by checking the PHB version via a 'version' attribute that can be set via a global machine property. The 'version' field will be used to make adjustments based on the running version, e.g. PHB3 uses a 'chip' reference while PHB4 uses 'pec'. To init the PnvPHB bus we'll rely on helpers for each version. The version 3 helper is already added (pnv_phb3_bus_init), the PHB4 helper will be added later on. For now let's add the basic logic of the PnvPHB object, which consists mostly of pnv_phb_realize() doing all the work of checking the phb->version set, initializing the proper backend, passing through its attributes to the chosen backend, finalizing the backend realize and adding a root port in the end. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-3-danielhb413@gmail.com>
2022-08-31ppc/pnv: add PHB3 bus init helperDaniel Henrique Barboza1-16/+23
The PnvPHB3 bus init consists of initializing the pci_io and pci_mmio regions, registering it via pci_register_root_bus() and then setup the iommu. We'll want to init the bus from outside pnv_phb3.c when the bus is removed from the PnvPHB3 device and put into a new parent PnvPHB device. The new pnv_phb3_bus_init() helper will be used by the parent to init the bus when using the PHB3 backend. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-2-danielhb413@gmail.com>
2022-07-26i386/pc: create pci-host qdev prior to pc_memory_init()Joao Martins1-3/+2
At the start of pc_memory_init() we usually pass a range of 0..UINT64_MAX as pci_memory, when really its 2G (i440fx) or 32G (q35). To get the real user value, we need to get pci-host passed property for default pci_hole64_size. Thus to get that, create the qdev prior to memory init to better make estimations on max used/phys addr. This is in preparation to determine that host-phys-bits are enough and also for pci-hole64-size to be considered to relocate ram-above-4g to be at 1T (on AMD platforms). Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-3-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-06ppc: Define SETFIELD for the ppc targetAlexey Kardashevskiy1-16/+0
It keeps repeating, move it to the header. This uses __builtin_ffsll() to allow using the macros in #define. This is not using the QEMU's FIELD macros as this would require changing all such macros found in skiboot (the PPC PowerNV firmware). Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220628080544.1509428-1-aik@ozlabs.ru> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-07-06ppc/pnv: remove 'INTERFACE_PCIE_DEVICE' from phb4 root busDaniel Henrique Barboza1-4/+0
It's unneeded. No other PCIE_BUS implements this interface. Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Fixes: 4f9924c4d4cf ("ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridge") Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220621173436.165912-9-danielhb413@gmail.com>
2022-07-06ppc/pnv: remove 'INTERFACE_PCIE_DEVICE' from phb3 root busDaniel Henrique Barboza1-4/+0
It's unneeded. No other PCIE_BUS implements this interface. Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Fixes: 9ae1329ee2fe ("ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridge") Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220621173436.165912-8-danielhb413@gmail.com>
2022-07-06ppc/pnv: assign pnv-phb-root-port chassis/slot earlierDaniel Henrique Barboza2-32/+4
It is not advisable to execute an object_dynamic_cast() to poke into bus->qbus.parent and follow it up with a C cast into the PnvPHB type we think we got. In fact this is not needed. There is nothing sophisticated being done with the PHB object retrieved during root_port_realize() for both PHB3 and PHB4. We're retrieving a PHB reference just to access phb->chip_id and phb->phb_id and use them to define the chassis/slot of the root port. phb->phb_id is already being passed to pnv_phb_attach_root_port() via the 'index' parameter. Let's also add a 'chip_id' parameter to this function and assign chassis and slot right there. This will spare us from the hassle of accessing the PHB object inside realize(). Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220621173436.165912-4-danielhb413@gmail.com>
2022-07-06ppc/pnv: attach phb3/phb4 root ports in QOM treeDaniel Henrique Barboza2-2/+2
At this moment we leave the pnv-phb3(4)-root-port unattached in QOM: /unattached (container) (...) /device[2] (pnv-phb3-root-port) /bus master container[0] (memory-region) /bus master[0] (memory-region) /pci_bridge_io[0] (memory-region) /pci_bridge_io[1] (memory-region) /pci_bridge_mem[0] (memory-region) /pci_bridge_pci[0] (memory-region) /pci_bridge_pref_mem[0] (memory-region) /pci_bridge_vga_io_hi[0] (memory-region) /pci_bridge_vga_io_lo[0] (memory-region) /pci_bridge_vga_mem[0] (memory-region) /pcie.0 (PCIE) Let's make changes in pnv_phb_attach_root_port() to attach the created root ports to its corresponding PHB. This is the result afterwards: /pnv-phb3[0] (pnv-phb3) /lsi (ics) /msi (phb3-msi) /msi32[0] (memory-region) /msi64[0] (memory-region) /pbcq (pnv-pbcq) (...) /phb3_iommu[0] (pnv-phb3-iommu-memory-region) /pnv-phb3-root.0 (pnv-phb3-root) /pnv-phb3-root-port[0] (pnv-phb3-root-port) /bus master container[0] (memory-region) /bus master[0] (memory-region) /pci_bridge_io[0] (memory-region) /pci_bridge_io[1] (memory-region) /pci_bridge_mem[0] (memory-region) /pci_bridge_pci[0] (memory-region) /pci_bridge_pref_mem[0] (memory-region) /pci_bridge_vga_io_hi[0] (memory-region) /pci_bridge_vga_io_lo[0] (memory-region) /pci_bridge_vga_mem[0] (memory-region) /pcie.0 (PCIE) Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220621173436.165912-3-danielhb413@gmail.com>
generated by cgit v1.1 at 2024-08-06 08:15:59 +0000