aboutsummaryrefslogtreecommitdiff
path: root/hw/pci-host
AgeCommit message (Collapse)Author
2022-01-12ppc/pnv: Introduce user creatable pnv-phb4 devicesDaniel Henrique Barboza
This patch introduces pnv-phb4 user creatable devices that are created in a similar manner as pnv-phb3 devices, allowing the user to interact with the PHBs directly instead of creating PCI Express Controllers that will create a certain amount of PHBs per controller index. We accomplish this by doing the following: - add a pnv_phb4_get_stack() helper to retrieve which stack an user created phb4 would occupy; - when dealing with an user created pnv-phb4 (detected by checking if phb->stack is NULL at the start of phb4_realize()), retrieve its stack and initialize its properties as done in stk_realize(); - use 'defaults_enabled()' in stk_realize() to avoid creating and initializing a 'stack->phb' qdev that might be overwritten by an user created pnv-phb4 device. This process is wrapped into a new helper called pnv_pec_stk_default_phb_realize(). Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: turn 'phb' into a pointer in struct PnvPhb4PecStackDaniel Henrique Barboza
At this moment, stack->phb is the plain PnvPHB4 device itself instead of a pointer to the device. This will present a problem when adding user creatable devices because we can't deal with this struct and the realize() callback from the user creatable device. We can't get rid of this attribute, similar to what we did when enabling pnv-phb3 user creatable devices, because pnv_phb4_update_regions() needs to access stack->phb to do its job. This function is called twice in pnv_pec_stk_update_map(), which is one of the nested xscom write callbacks (via pnv_pec_stk_nest_xscom_write()). In fact, pnv_pec_stk_update_map() code comment is explicit about how the order of the unmap/map operations relates with the PHB subregions. All of this indicates that this code is tied together in a way that we either go on a crusade, featuring lots of refactories and redesign and considerable pain, to decouple stack and phb mapping, or we allow stack update_map operations to access the associated PHB as it is today even after introducing pnv-phb4 user devices. This patch chooses the latter. Instead of getting rid of stack->phb, turn it into a PHB pointer. This will allow us to assign an user created PHB to an existing stack later. In this process, pnv_pec_stk_instance_init() is removed because stack->phb is being initialized in stk_realize() instead. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: move PHB4 XSCOM init to phb4_realize()Daniel Henrique Barboza
The 'stack->phb_regs_mr' PHB4 passthrough XSCOM initialization relies on 'stack->phb' being not NULL. Moving 'stack->phb_regs_mr' region_init() and add_subregion() to phb4_realize() time is a natural thing to do since it's strictly PHB related. The remaining XSCOM initialization is also related to 'stack->phb' but in a different manner. For instance, 'stack->nest_regs_mr' MemoryRegionOps, 'pnv_pec_stk_nest_xscom_ops', uses pnv_pec_stk_nest_xscom_write() as a write callback. When trying to write the PEC_NEST_STK_BAR_EN reg, pnv_pec_stk_update_map() is called. Inside this function, pnv_phb4_update_regions() is called twice. This function uses 'stack->phb' to manipulate memory regions of the phb. This is not a problem now but, when enabling user creatable phb4s, a stack that doesn't have an associated phb (i.e. stack->phb = NULL) it will cause a SIGINT during boot in pnv_phb4_update_regions(). All this can be avoided if all XSCOM realize is moved to phb4_realize(), when we have certainty about the existence of 'stack->phb'. A lot of code was moved from pnv_phb4_pec.c to pnv_phb4.c due to static constant and variables being used but the cleaner logic is worth the trouble. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: set phb4 properties in stk_realize()Daniel Henrique Barboza
Moving all phb4 properties setup to stk_realize() keeps this logic in a single place instead of having it scattered between stk_realize() and pec_realize(). 'phb->index' can be retrieved using stack->stack_no and pnv_phb4_pec_get_phb_id(), deprecating the use of 'phb-id' alias that was being used for this purpose in pec_realize(). Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4_pec: use pnv_phb4_pec_get_phb_id() in pnv_pec_dt_xscom()Daniel Henrique Barboza
Relying on stack->phb to write the xscom DT of the PEC is something that we won't be able to do with user creatable pnv-phb4 devices. Hopefully, this can be done by using pnv_phb4_pec_get_phb_id(), which is already used by pnv_pec_realize() to set the phb-id of the stack. Use the same idea in pnv_pec_dt_xscom() to write ibm,phb-index without the need to accessing stack->phb, since stack->phb is not granted to be != NULL when user creatable phbs are introduced. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220110143346.455901-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.cDaniel Henrique Barboza
The logic inside pnv_pec_phb_offset() will be useful in the next patch to determine the stack that should contain a PHB4 device. Move the function to pnv_phb4.c and make it public since there's no pnv_phb4_pec.h header. While we're at it, add 'stack_index' as a parameter and make the function return 'phb-id' directly. And rename it to pnv_phb4_pec_get_phb_id() to be even clearer about the function intent. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220110143346.455901-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Complete user created PHB3 devicesCédric Le Goater
PHB3s ared SysBus devices and should be allowed to be dynamically created. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-9-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Reparent user created PHB3 devices to the PnvChipCédric Le Goater
The powernv machine uses the object hierarchy to populate the device tree and each device should be parented to the chip it belongs to. This is not the case for user created devices which are parented to the container "/unattached". Make sure a PHB3 device is parented to its chip by reparenting the object if necessary. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-8-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Introduce support for user created PHB3 devicesCédric Le Goater
PHB3 devices and PCI devices can now be added to the powernv8 machine using : -device pnv-phb3,chip-id=0,index=1 \ -device nec-usb-xhci,bus=pci.1,addr=0x0 The 'index' property identifies the PHB3 in the chip. In case of user created devices, a lookup on 'chip-id' is required to assign the owning chip. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-7-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4.c: check if root port exists in rc_config functionsDaniel Henrique Barboza
pnv_phb4_rc_config_read() and pnv_phb4_rc_config_write() are asserting the existence of the root port. The root port is now optional, and there will be cases where a pnv-phb4 device won't have a root port attached. Instead of asserting, check if the root port exists before read/writing into it. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-6-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4.c: make pnv-phb4-root-port user creatableDaniel Henrique Barboza
We want to create only the absolutely minimal amount of devices when running with -nodefaults. The root port is something that the machine can boot up without. But, to do that, we need to provide a way for the user to add them by hand. This patch makes pnv-phb4-root-port user creatable and then uses the pnv_phb_attach_root_port() helper to add a pnv_phb4_root_port only when running with default settings. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Attach PHB3 root port device when defaults are enabledCédric Le Goater
This cleanups the PHB3 model a bit more since the root port is an independent device and it will ease our task when adding user created PHB3s. pnv_phb_attach_root_port() is made public in pnv.c so it can be reused with the pnv_phb4 root port later. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4.c: add unique chassis and slot for pnv_phb4_root_portDaniel Henrique Barboza
A similar situation as described previously with pnv_phb3_root_port devices also happens with pnv_phb4_root_ports. The solution is the same: assign an unique chassis/slot combo for them. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb3.c: add unique chassis and slot for pnv_phb3_root_portDaniel Henrique Barboza
When creating a pnv_phb3_root_port using the command line, the first root port is created successfully, but the second fails with the following error: qemu-system-ppc64: -device pnv-phb3-root-port,bus=phb3-root.0,id=pcie.3: Can't add chassis slot, error -16 This error comes from the realize() function of its parent type, rp_realize() from TYPE_PCIE_ROOT_PORT. pcie_chassis_add_slot() fails with -EBUSY if there's an existing PCIESlot that has the same chassis/slot value, regardless of being in a different bus. One way to prevent this error is simply set chassis and slot values in the command line. However, since phb3 root buses only supports a single root port, we can just get an unique chassis/slot value by checking which root bus the pnv_phb3_root_port is going to be attached, get the equivalent phb3 device and use its chip-id and index values, which are guaranteed to be unique. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-04pnv_phb4.c: do not set 'root-bus' as bus nameDaniel Henrique Barboza
This change has the same motivation as the one done for pnv-phb3-root-bus buses previously. Defaulting every bus to 'root-bus' makes it impossible to attach root ports to specific buses and it doesn't allow for custom bus naming because we're ignoring the 'id' value when registering the root bus. After this patch, creating pnv-phb4 devices with 'id' being set will result in the following qtree: qemu-system-ppc64 -m 4G -machine powernv9,accel=tcg \ -device pnv-phb4,chip-id=0,index=0,id=pcie.0 \ -device pnv-phb4,chip-id=1,index=4,id=pcie.1 bus: main-system-bus type System dev: pnv-phb4, id "pcie.1" index = 4 (0x4) chip-id = 1 (0x1) version = 704374636546 (0xa400000002) device-id = 1217 (0x4c1) x-config-reg-migration-enabled = true bypass-iommu = false bus: pcie.1 type pnv-phb4-root-bus dev: pnv-phb4, id "pcie.0" index = 0 (0x0) chip-id = 0 (0x0) version = 704374636546 (0xa400000002) device-id = 1217 (0x4c1) x-config-reg-migration-enabled = true bypass-iommu = false bus: pcie.0 type pnv-phb4-root-bus And without setting any ids: qemu-system-ppc64 -m 4G -machine powernv9,accel=tcg \ -device pnv-phb4,chip-id=0,index=0,id=pcie.0 \ -device pnv-phb4,chip-id=1,index=4,id=pcie.1 bus: main-system-bus type System dev: pnv-phb4, id "" index = 4 (0x4) chip-id = 1 (0x1) version = 704374636546 (0xa400000002) device-id = 1217 (0x4c1) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb4-root-bus.1 type pnv-phb4-root-bus dev: pnv-phb4, id "" index = 0 (0x0) chip-id = 0 (0x0) version = 704374636546 (0xa400000002) device-id = 1217 (0x4c1) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb4-root-bus.0 type pnv-phb4-root-bus Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211228193806.1198496-17-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-04pnv_phb3.c: do not set 'root-bus' as bus nameDaniel Henrique Barboza
All pnv-phb3-root-bus buses are being created as 'root-bus'. This makes it impossible to, for example, add a pnv-phb3-root-port in a specific root bus, since they all have the same name. By default the device will be parented by the pnv-phb3 device that precedeced it in the QEMU command line. Moreover, this doesn't all for custom bus naming. Libvirt, for instance, likes to name these buses as 'pcie.N', where 'N' is the index value of the controller in the domain XML, by using the 'id' command line attribute. At this moment this is also being ignored - the created root bus will always be named 'root-bus'. This patch fixes both scenarios by removing the 'root-bus' name from the pci_register_root_bus() call. If an "id" is provided, use that. Otherwise use 'NULL' as bus name. The 'NULL' value will be handled in qbus_init_internal() and it will defaulted as lowercase bus type + the global bus_id value. After this path we can define the bus name by using the 'id' attribute: qemu-system-ppc64 -m 4G -machine powernv8,accel=tcg \ -device pnv-phb3,chip-id=0,index=1,id=pcie.0 dev: pnv-phb3, id "pcie.0" index = 1 (0x1) chip-id = 0 (0x0) x-config-reg-migration-enabled = true bypass-iommu = false bus: pcie.0 type pnv-phb3-root-bus And without an 'id' we will have the following default: qemu-system-ppc64 -m 4G -machine powernv8,accel=tcg \ -device pnv-phb3,chip-id=0,index=1 dev: pnv-phb3, id "" index = 1 (0x1) chip-id = 0 (0x0) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb3-root-bus.0 type pnv-phb3-root-bus Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211228193806.1198496-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-04ppc/pnv: Remove the PHB4 "device-id" propertyCédric Le Goater
It's unused. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211222063817.1541058-4-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-04ppc/pnv: Remove PHB4 reset handlerCédric Le Goater
The PHB4 reset handler was preparing ground for PHB5 to set appropriately the device id. We don't need it for the PHB4 since the device id is already set in the root port complex. PH5 will introduce its own. "device-id" property is now useless. It should be removed. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211222063817.1541058-3-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-30dma: Let dma_memory_read/write() take MemTxAttrs argumentPhilippe Mathieu-Daudé
Let devices specify transaction attributes when calling dma_memory_read() or dma_memory_write(). Patch created mechanically using spatch with this script: @@ expression E1, E2, E3, E4; @@ ( - dma_memory_read(E1, E2, E3, E4) + dma_memory_read(E1, E2, E3, E4, MEMTXATTRS_UNSPECIFIED) | - dma_memory_write(E1, E2, E3, E4) + dma_memory_write(E1, E2, E3, E4, MEMTXATTRS_UNSPECIFIED) ) Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20211223115554.3155328-6-philmd@redhat.com>
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: 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: Use the chip class to check the index of PHB3 devicesCédric Le Goater
The maximum number of PHB3 devices per chip can be different depending on the POWER8 processor model. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211213132830.108372-4-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-17pci-host: Allow extended config space access for PowerNV PHB4 modelChristophe Lombard
The PCIe extended configuration space on the device is not currently accessible to the host. if by default, it is still inaccessible for conventional for PCIe buses, add the current flag PCI_BUS_EXTENDED_CONFIG_SPACE on the root bus permits PCI-E extended config space access. Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211109145053.43524-1-clombard@linux.vnet.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-10-30hw/sh4: Coding style: White space fixesBALATON Zoltan
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Yoshinori Sato <ysato@users.sourceforge.jp> Message-Id: <91698c54fa493a4cfe93546211206439787d4b78.1635541329.git.balaton@eik.bme.hu> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
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-09-30pci: Rename pci_root_bus_new_inplace() to pci_root_bus_init()Peter Maydell
Rename the pci_root_bus_new_inplace() function to pci_root_bus_init(); this brings the bus type in to line with a "_init for in-place init, _new for allocate-and-return" convention. To do this we need to rename the implementation-internal function that was using the pci_root_bus_init() name to pci_root_bus_internal_init(). 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> Message-id: 20210923121153.23754-4-peter.maydell@linaro.org
2021-09-04hw/pci: remove all references to find_i440fx functionAni Sinha
commit c0e427d6eb5fefc538 ("hw/acpi/ich9: Enable ACPI PCI hot-plug") removed all uses of find_i440fx() function. This has been replaced by the more generic call acpi_get_i386_pci_host() which maybe able to find the root bus both for i440fx machine type as well as for the q35 machine type. There seems to be no more any need to maintain a i440fx specific version of the api call. Remove it. Tested by building from a clean tree successfully. Signed-off-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210825031949.919376-2-ani@anisinha.ca> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-09-04Use PCI_HOST_BRIDGE macroEduardo Habkost
OBJECT_CHECK(PciHostState, ..., TYPE_PCI_HOST_BRIDGE) is exactly what the PCI_HOST_BRIDGE macro does. We can just use the macro instead of using OBJECT_CHECK manually. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210805193431.307761-7-ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-08-03Revert "acpi/gpex: Inform os to keep firmware resource map"Michael S. Tsirkin
This reverts commit 0cf8882fd06ba0aeb1e90fa6f23fce85504d7e14. Which this commit, with aarch64 when using efi PCI devices with IO ports do not work. The reason is that EFI creates I/O port mappings below 0x1000 (in fact, at 0). However Linux, for legacy reasons, does not support I/O ports <= 0x1000 on PCI, so the I/O assignment created by EFI is rejected. EFI creates the mappings primarily for itself, and up until DSM #5 started to be enforced, all PCI resource allocations that existed at boot were ignored by Linux and recreated from scratch. Also, the commit in question looks dubious - it seems unlikely that Linux would fail to create a resource tree. What does happen is that BARs get moved around, which may cause trouble in some cases: for instance, Linux had to add special code to the EFI framebuffer driver to copy with framebuffer BARs being relocated. DSM #5 has a long history of debate and misinterpretation. Link: https://lore.kernel.org/r/20210724185234.GA2265457@roeck-us.net/ Fixes: 0cf8882fd06 ("acpi/gpex: Inform os to keep firmware resource map") Reported-by: Guenter Roeck <linux@roeck-us.net> Suggested-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-07-26hw/pci-hist/pnv_phb4: Fix typo in pnv_phb4_ioda_writeRichard Henderson
From clang-13: hw/pci-host/pnv_phb4.c:375:18: error: variable 'v' set but not used \ [-Werror,-Wunused-but-set-variable] It's pretty clear that we meant to write back 'v' after all that computation and not 'val'. Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-07-20hw/pci-host/Kconfig: Add missing dependency MV64361 -> I8259Philippe Mathieu-Daudé
Looking at the MV64341 model source, there is a dependency on the 8259 interrupt controller: 523 case MV64340_PCI_1_INTERRUPT_ACKNOWLEDGE_VIRTUAL_REG: 524 /* FIXME: Should this be sent via the PCI bus somehow? */ 525 if (s->gpp_int_level && (s->gpp_value & BIT(31))) { 526 ret = pic_read_irq(isa_pic); 527 } 528 break; Add it to Kconfig to avoid the following build failure: /usr/bin/ld: libcommon.fa.p/hw_pci-host_mv64361.c.o: in function `mv64361_read': hw/pci-host/mv64361.c:526: undefined reference to `isa_pic' /usr/bin/ld: hw/pci-host/mv64361.c:526: undefined reference to `pic_read_irq' Fixes: dcdf98a9015 ("hw/pci-host: Add emulation of Marvell MV64361 PPC system controller") Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20210515173716.358295-10-philmd@redhat.com>
2021-07-16hw/i386: Add a default_bus_bypass_iommu pc machine optionXingang Wang
Add a default_bus_bypass_iommu pc machine option to enable/disable bypass_iommu for default root bus. The option is disabled by default and can be enabled with: $QEMU -machine q35,default_bus_bypass_iommu=true Signed-off-by: Xingang Wang <wangxingang5@huawei.com> Message-Id: <1625748919-52456-5-git-send-email-wangxingang5@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-07-13mv64361: Remove extra break from a switch caseBALATON Zoltan
The switch case of writing PCI 1 IO base address had an extra break statement that made part of the code unreachable. This did not cause a problem as guests ususally leave this register at its default value. Fixes: dcdf98a9015 ("Add emulation of Marvell MV64361 PPC system controller") Reported-by: Coverity (CID 1458135) Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20210712131259.B705B7456E3@zero.eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-11hw/pci-host/raven: Add PCI_IO_BASE_ADDR definitionPhilippe Mathieu-Daudé
Rather than using the magic 0x80000000 number for the PCI I/O BAR physical address on the main system bus, use a definition. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20210417103028.601124-6-f4bug@amsat.org>
2021-07-11hw/pci-host: Rename Raven ASIC PCI bridge as raven.cPhilippe Mathieu-Daudé
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-09Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
pc,pci,virtio: bugfixes, improvements vhost-user-rng support. Fixes all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Wed 07 Jul 2021 14:29:30 BST # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: MAINTAINERS: Add maintainer for vhost-user RNG implementation docs: add slot when adding new PCIe root port acpi/ged: fix reset cause tests: acpi: pc: update expected DSDT blobs acpi: pc: revert back to v5.2 PCI slot enumeration tests: acpi: prepare for changing DSDT tables migration: failover: reset partially_hotplugged virtio-pci: Changed return values for "notify", "device" and "isr" read. virtio-pci: Added check for virtio device in PCI config cbs. virtio-pci: Added check for virtio device presence in mm callbacks. hw/pci-host/q35: Ignore write of reserved PCIEXBAR LENGTH field virtio: Clarify MR transaction optimization virtio: disable ioeventfd for record/replay Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-03hw/pci-host/q35: Ignore write of reserved PCIEXBAR LENGTH fieldPhilippe Mathieu-Daudé
libFuzzer triggered the following assertion: cat << EOF | qemu-system-i386 -M pc-q35-5.0 \ -nographic -monitor none -serial none \ -qtest stdio -d guest_errors -trace pci\* outl 0xcf8 0xf2000060 outl 0xcfc 0x8400056e EOF pci_cfg_write mch 00:0 @0x60 <- 0x8400056e Aborted (core dumped) This is because guest wrote MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_RVD (reserved value) to the PCIE XBAR register. There is no indication on the datasheet about what occurs when this value is written. Simply ignore it on QEMU (and report an guest error): pci_cfg_write mch 00:0 @0x60 <- 0x8400056e Q35: Reserved PCIEXBAR LENGTH pci_cfg_read mch 00:0 @0x0 -> 0x8086 pci_cfg_read mch 00:0 @0x0 -> 0x29c08086 ... Cc: qemu-stable@nongnu.org Reported-by: Alexander Bulekov <alxndr@bu.edu> BugLink: https://bugs.launchpad.net/qemu/+bug/1878641 Fixes: df2d8b3ed4 ("q35: Introduce q35 pc based chipset emulator") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210526142438.281477-1-f4bug@amsat.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-07-02hw/pci-host/bonito: Allow PCI config accesses smaller than 32-bitPhilippe Mathieu-Daudé
When running the official PMON firmware for the Fuloong 2E, we see 8-bit and 16-bit accesses to PCI config space: $ qemu-system-mips64el -M fuloong2e -bios pmon_2e.bin \ -trace -trace bonito\* -trace pci_cfg\* pci_cfg_write vt82c686b-pm 05:4 @0x90 <- 0xeee1 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x4d2, size: 2 pci_cfg_write vt82c686b-pm 05:4 @0xd2 <- 0x1 pci_cfg_write vt82c686b-pm 05:4 @0x4 <- 0x1 pci_cfg_write vt82c686b-isa 05:0 @0x4 <- 0x7 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x81, size: 1 pci_cfg_read vt82c686b-isa 05:0 @0x81 -> 0x0 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x81, size: 1 pci_cfg_write vt82c686b-isa 05:0 @0x81 <- 0x80 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x83, size: 1 pci_cfg_write vt82c686b-isa 05:0 @0x83 <- 0x89 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x85, size: 1 pci_cfg_write vt82c686b-isa 05:0 @0x85 <- 0x3 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x5a, size: 1 pci_cfg_write vt82c686b-isa 05:0 @0x5a <- 0x7 bonito_spciconf_small_access PCI config address is smaller then 32-bit, addr: 0x85, size: 1 pci_cfg_write vt82c686b-isa 05:0 @0x85 <- 0x1 Also this is what the Linux kernel does since it supports the Bonito north bridge: https://elixir.bootlin.com/linux/v2.6.15/source/arch/mips/pci/ops-bonito64.c#L85 So it seems safe to assume the datasheet is incomplete or outdated regarding the address constraints. This problem was exposed by commit 911629e6d3773a8adeab48b ("vt82c686: Fix SMBus IO base and configuration registers"). Reported-by: BALATON Zoltan <balaton@eik.bme.hu> Suggested-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210624202747.1433023-4-f4bug@amsat.org> Tested-by: BALATON Zoltan <balaton@eik.bme.hu>
2021-07-02hw/pci-host/bonito: Trace PCI config accesses smaller than 32-bitPhilippe Mathieu-Daudé
Per the datasheet section "5.7.5. Accessing PCI configuration space" the address must be 32-bit aligned. Trace eventual accesses not aligned to 32-bit. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210624202747.1433023-3-f4bug@amsat.org>
2021-06-02docs: fix references to docs/devel/tracing.rstStefano Garzarella
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-13hw/pci-host: Do not build gpex-acpi.c if GPEX is not selectedPhilippe Mathieu-Daudé
Since its introduction in commit 5b85eabe68f ("acpi: add acpi_dsdt_add_gpex") we build gpex-acpi.c if ACPI is selected, even if the GPEX_HOST device isn't build. Add the missing Kconfig dependency. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20210425182124.3735214-1-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-05Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.1-20210504' ↵Peter Maydell
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/pci-host: Add emulation of Marvell MV64361 PPC system controllerBALATON Zoltan
The Marvell Discovery II aka. MV64361 is a PowerPC system controller chip that is used on the pegasos2 PPC board. This adds emulation of it that models the device enough to boot guests on this board. The mv643xx.h header with register definitions is taken from Linux 4.15.10 only fixing white space errors, removing not needed parts and changing formatting for QEMU coding style. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <79545ebd03bfe0665b73d2d7cbc74fdf3d62629e.1616680239.git.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 Huth
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>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-16 18:41:50 +0000