aboutsummaryrefslogtreecommitdiff
path: root/hw/pci-host
AgeCommit message (Collapse)Author
2022-01-18ppc/pnv: move nest_regs_mr to PnvPHB4Daniel Henrique Barboza
We're now able to cleanly move nest_regs_mr to the PnvPHB4 device. One thing of notice here is the need to use a phb->stack->pec pointer because pnv_pec_stk_nest_xscom_write requires a PEC object. Another thing that can be noticed in the use of 'stack->stack_no' that still remains throughout the XSCOM code. After moving all MemoryRegions to the PnvPHB4 object, this illustrates what is the remaining role of the stack: provide a PEC pointer and the 'stack_no' information. If we can provide these in the PnvPHB4 object instead (spoiler: we can, and we will), the PnvPhb4PecStack device will be deprecated and can be removed. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-10-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: change pnv_pec_stk_update_map() to use PnvPHB4Daniel Henrique Barboza
stack->nest_regs_mr wasn't migrated to PnvPHB4 together with phb->nest_regs[] in the previous patch. We were unable to cleanly convert its write MemoryRegionOps, pnv_pec_stk_nest_xscom_write(), to use PnvPHB4 instead of PnvPhb4PecStack due to pnv_pec_stk_update_map() using a stack. Thing is, we're now able to convert pnv_pec_stk_update_map() because of what the did in previous patch. The need for this intermediate step is a good example of the interconnected relationship between stack and phb that we aim to cleanup. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-9-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move nest_regs[] to PnvPHB4Daniel Henrique Barboza
stack->nest_regs[] is used in several XSCOM functions and it's one of the main culprits of having to deal with stack->phb pointers around the code. Sure, we're having to add 2 extra stack->phb pointers to ease nest_regs[] migration to PnvPHB4. They'll be dealt with shortly. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-8-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move mmbar0/mmbar1 and friends to PnvPHB4Daniel Henrique Barboza
These 2 MemoryRegions, together with mmio(0|1)_base and mmio(0|1)_size variables, are used together in the same functions. We're better of moving them all in a single step. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-7-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: change pnv_phb4_update_regions() to use PnvPHB4Daniel Henrique Barboza
The function does not rely on stack for anything it does anymore. This is also one less instance of 'stack->phb' that we need to worry about. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-6-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move intbar to PnvPHB4Daniel Henrique Barboza
This MemoryRegion can also be moved in a single step. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move phbbar to PnvPHB4Daniel Henrique Barboza
This MemoryRegion is simple enough to be moved in a single step. A 'stack->phb' pointer had to be introduced in pnv_pec_stk_update_map() because this function isn't ready to be fully converted to use a PnvPHB4 pointer instead. This will be dealt with in the following patches. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move PCI registers to PnvPHB4Daniel Henrique Barboza
Previous patch changed pnv_pec_stk_pci_xscom_read() and pnv_pec_stk_pci_xscom_write() to use a PnvPHB4 opaque, making it easier to move both pci_regs[] and the pci_regs_mr MemoryRegion to the PnvHB4 object. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: use PHB4 obj in pnv_pec_stk_pci_xscom_opsDaniel Henrique Barboza
The current relationship between PnvPhb4PecStack and PnvPHB4 objects is overly complex. Recent work done in pnv_phb4.c and pnv_phb4_pec.c shows that the stack obj role in the overall design is more of a placeholder for its 'phb' object, having no atributes that stand on its own. This became clearer after pnv-phb4 user creatable devices were implemented. What remains now are a lot of stack->phb and phb->stack pointers throughout .read and .write callbacks of MemoryRegionOps that are being initialized in phb4_realize() time. stk_realize() is a no-op if the machine is being run with -nodefaults. The first step of trying to decouple the stack and phb relationship is to move the MemoryRegionOps that belongs to PnvPhb4PecStack to PhbPHB4. Unfortunately this can't be done without some preliminary steps to change the usage of 'stack' and replace it with 'phb' in these read/write callbacks. This patch starts this process by using a PnvPHB4 opaque in pnv_pec_stk_pci_xscom_ops instead of PnvPhb4PecStack. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: use stack->pci_regs[] in pnv_pec_stk_pci_xscom_write()Daniel Henrique Barboza
pnv_pec_stk_pci_xscom_write() is pnv_pec_stk_pci_xscom_ops write callback. It writes values into regs in the stack->nest_regs[] array. The pnv_pec_stk_pci_xscom_read read callback, on the other hand, returns values of the stack->pci_regs[]. In fact, at this moment, the only use of stack->pci_regs[] is in pnv_pec_stk_pci_xscom_read(). There's no code that is written anything in stack->pci_regs[], which is suspicious. Considering that stack->nest_regs[] is widely used by the nested MemoryOps pnv_pec_stk_nest_xscom_ops, in both read and write callbacks, the conclusion is that we're writing the wrong array in pnv_pec_stk_pci_xscom_write(). This function should write stack->pci_regs[] instead. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220111200132.633896-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: turn pnv_phb4_update_regions() into staticDaniel Henrique Barboza
Its only callers are inside pnv_phb4.c. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-6-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
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>