summaryrefslogtreecommitdiffstats
path: root/hw/pci-host/pnv_phb4.c
Commit message (Collapse)AuthorAgeFilesLines
* ppc/pnv: Remove LSI on the PCIE host bridgeFrederic Barrat2022-04-201-0/+1
| | | | | | | | | | | | | | | | | The phb3/phb4/phb5 root ports inherit from the default PCIE root port implementation, which requests a LSI interrupt (#INTA). On real hardware (POWER8/POWER9/POWER10), there is no such LSI. This patch corrects it so that it matches the hardware. As a consequence, the device tree previously generated was bogus, as the root bridge LSI was not properly mapped. On some implementation (powernv9), it was leading to inconsistent interrupt controller (xive) data. With this patch, it is now clean. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220408131303.147840-3-fbarrat@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
* Remove qemu-common.h include from most unitsMarc-André Lureau2022-04-061-1/+0Star
| | | | | | Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20220323155743.1585078-33-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* Use g_new() & friends where that makes obvious senseMarkus Armbruster2022-03-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, for two reasons. One, it catches multiplication overflowing size_t. Two, it returns T * rather than void *, which lets the compiler catch more type errors. This commit only touches allocations with size arguments of the form sizeof(T). Patch created mechanically with: $ spatch --in-place --sp-file scripts/coccinelle/use-g_new-etc.cocci \ --macro-file scripts/cocci-macro-file.h FILES... Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20220315144156.1595462-4-armbru@redhat.com> Reviewed-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
* ppc/pnv: Remove user-created PHB{3,4,5} devicesCédric Le Goater2022-03-141-59/+3Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On a real system with POWER{8,9,10} processors, PHBs are sub-units of the processor, they can be deactivated by firmware but not plugged in or out like a PCI adapter on a slot. Nevertheless, having user-created PHBs in QEMU seemed to be a good idea for testing purposes : 1. having a limited set of PHBs speedups boot time. 2. it is useful to be able to mimic a partially broken topology you some time have to deal with during bring-up. PowerNV is also used for distro install tests and having libvirt support eases these tasks. libvirt prefers to run the machine with -nodefaults to be sure not to drag unexpected devices which would need to be defined in the domain file without being specified on the QEMU command line. For this reason : 3. -nodefaults should not include default PHBs User-created PHB{3,4,5} devices satisfied all these needs but reality proves to be a bit more complex, internally when modeling such devices, and externally when dealing with the user interface. Req 1. and 2. can be simply addressed differently with a machine option: "phb-mask=<uint>", which QEMU would use to enable/disable PHB device nodes when creating the device tree. For Req 3., we need to make sure we are taking the right approach. It seems that we should expose a new type of user-created PHB device, a generic virtualized one, that libvirt would use and not one depending on the processor revision. This needs more thinking. For now, remove user-created PHB{3,4,5} devices. All the cleanups we did are not lost and they will be useful for the next steps. Fixes: 5bc67b052b51 ("ppc/pnv: Introduce user creatable pnv-phb4 devices") Fixes: 1f6a88fffc75 ("ppc/pnv: Introduce 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: <20220314130514.529931-1-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: Introduce a pnv-phb5 device to match root portFrederic Barrat2022-03-141-0/+7
| | | | | | | | | | | | | | | | | | | | We already have the pnv-phb3 and pnv-phb4 devices for POWER8 and POWER9 respectively. POWER10 uses version 5 of the PHB. It is very close to the PHB4 from POWER9, at least in our model and we could almost keep using the PHB4 model. However the matching root port pnv-phb5-root-port is specific to POWER10 so to avoid confusion as well as making it easy to introduce differences later, we create a pnv-phb5 class, which is mostly an alias for pnv-phb4 for now. With this patch, the command line for a user-created PHB on powernv10 becomes: -machine powernv10 -nodefaults -device pnv-phb5 -device pnv-phb5-root-port Fixes: 623575e16cd5 ("ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge") Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220310155101.294568-2-fbarrat@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: Add support for PHB5 "Address-based trigger" modeCédric Le Goater2022-03-021-6/+67
| | | | | | | | | | When the Address-Based Interrupt Trigger mode is activated, the PHB maps the interrupt source number into the interrupt command address. The PHB directly triggers the IC ESB page of the interrupt number and not the notify page of the IC anymore. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: Add support for PQ offload on PHB5Cédric Le Goater2022-03-021-0/+9
| | | | | | | | | | | | | | | | | The PQ_disable configuration bit disables the check done on the PQ state bits when processing new MSI interrupts. When bit 9 is enabled, the PHB forwards any MSI trigger to the XIVE interrupt controller without checking the PQ state bits. The XIVE IC knows from the trigger message that the PQ bits have not been checked and performs the check locally. This configuration bit only applies to MSIs and LSIs are still checked on the PHB to handle the assertion level. PQ_disable enablement is a requirement for StoreEOI. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/xive: Add support for PQ state bits offloadCédric Le Goater2022-03-021-2/+7
| | | | | | | | | | | | | | | | The trigger message coming from a HW source contains a special bit informing the XIVE interrupt controller that the PQ bits have been checked at the source or not. Depending on the value, the IC can perform the check and the state transition locally using its own PQ state bits. The following changes add new accessors to the XiveRouter required to query and update the PQ state bits. This only applies to the PowerNV machine. sPAPR accessors are provided but the pSeries machine should not be concerned by such complex configuration for the moment. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridgeCédric Le Goater2022-03-021-0/+20
| | | | | | | PHB4 and PHB5 are very similar. Use the PHB4 models with some minor adjustements in a subclass for P10. Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: fix default PHB4 QOM hierarchyDaniel Henrique Barboza2022-03-021-20/+16Star
| | | | | | | | | | | | | | | | | | | | | | Commit 3f4c369ea63e ("ppc/pnv: make PECs create and realize PHB4s") changed phb4_pec code to create the default PHB4 objects in pnv_pec_default_phb_realize(). In this process the stacks[] PEC array was removed and each PHB4 object is tied together with its PEC via the phb->pec pointer. This change also broke the previous QOM hierarchy - the PHB4 objects are being created and not being parented to their respective chips. This can be verified by 'info pic' in a powernv9 domain with default settings. pnv_chip_power9_pic_print_info() will fail to find the PHBs because object_child_foreach_recursive() won't find any. The solution is to set the parent chip and the parent bus, in the same way done for user created PHB4 devices, for all PHB4 devices. Fixes: 3f4c369ea63e ("ppc/pnv: make PECs create and realize PHB4s") Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220218202804.413157-1-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: use a do-while() loop in pnv_phb4_translate_tve()Daniel Henrique Barboza2022-01-281-2/+4
| | | | | | | | | | | | | | | | pnv_phb4_translate_tve() is quite similar to pnv_phb3_translate_tve(), and that includes the fact that 'taddr' can be considered uninitialized when throwing the "TCE access fault" error because, in theory, the loop that sets 'taddr' can be skippable due to 'lev' being an signed int. No one complained about this specific case yet, but since we took the time to handle the same situtation in pnv_phb3_translate_tve(), let's replicate it here as well. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Message-Id: <20220127122234.842145-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: Fail DMA access if page permissions are not correctFrederic Barrat2022-01-281-5/+6
| | | | | | | | | | If an iommu page has wrong permissions, an error message is displayed, but the access is allowed, which is odd. This patch fixes it. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220121152350.381685-1-fbarrat@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: Remove PHB4 version propertyCédric Le Goater2022-01-181-8/+1Star
| | | | | | | | | Grab the PHB version from the PEC class directly when needed. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220117122753.1655504-4-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: Move root port allocation under pnv_pec_default_phb_realize()Cédric Le Goater2022-01-181-7/+0Star
| | | | | | | | | | | | The root port device is currently created and attached to the PHB early in pnv_phb4_realize(). Do it under pnv_pec_default_phb_realize() after the PHB is fully realized. It's cleaner and avoids an extra test on defaults_enabled(). Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220117122753.1655504-2-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: rename pnv_pec_stk_update_map()Daniel Henrique Barboza2022-01-181-2/+2
| | | | | | | | | | This function does not use 'stack' anymore. Rename it to pnv_pec_phb_update_map(). Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220114180719.52117-9-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: make PECs create and realize PHB4sDaniel Henrique Barboza2022-01-181-16/+10Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the design of the PEC device to create and realize PHB4s instead of PecStacks. After all the recent changes, PHB4s now contain all the information needed for their proper functioning, not relying on PecStack in any capacity. All changes are being made in a single patch to avoid renaming parts of the PecState and leaving the code in a strange way. E.g. rename PecClass->num_stacks to num_phbs, which would then read a pnv_pec_num_stacks[] array. To avoid mixing the old and new design more than necessary it's clearer to do these changes in a single step. The name changes made are: - in PnvPhb4PecState: * rename 'num_stacks' to 'num_phbs' * remove the pec->stacks[] array. Current code relies on the pec->stacks[] obj acting as a simple container, without ever accessing pec->stacks[] for any other purpose. Instead of converting this into a pec->phbs[] array, remove it - in PnvPhb4PecClass, rename *num_stacks to *num_phbs; - pnv_pec_num_stacks[] is renamed to pnv_pec_num_phbs[]. The logical changes: - pnv_pec_default_phb_realize(): * init and set the properties of the PnvPHB4 qdev * do not use stack->phb anymore; - pnv_pec_realize(): * use the new default_phb_realize() to init/realize each PHB if running with defaults; - pnv_pec_instance_init(): removed since we're creating the PHBs during pec_realize(); - pnv_phb4_get_stack(): * renamed to pnv_phb4_get_pec() and returns a PnvPhb4PecState*; - pnv_phb4_realize(): use 'phb->pec' instead of 'stack'. This design change shouldn't caused any behavioral change in the runtime of the machine. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220114180719.52117-7-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: remove stack pointer from PnvPHB4Daniel Henrique Barboza2022-01-181-11/+4Star
| | | | | | | | | | | | | | | | | This pointer was being used for two reasons: pnv_phb4_update_regions() was using it to access the PHB and phb4_realize() was using it as a way to determine if the PHB was user created. We can determine if the PHB is user created via phb->pec, introduced in the previous patch, and pnv_phb4_update_regions() is no longer using stack->phb. Remove the pointer from the PnvPHB4 device. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220114180719.52117-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: reduce stack->stack_no usageDaniel Henrique Barboza2022-01-181-12/+34
| | | | | | | | | | | | | | | | | | | | | 'stack->stack_no' represents the order that a stack appears in its PEC. Its primary use is in XSCOM address space calculation in pnv_phb4_xscom_realize() when calculating the memory region offset. This attribute is redundant with phb->phb_id, which is calculated via pnv_phb4_pec_get_phb_id() using stack->stack_no information. It'll also be awkward to assign it when dealing with PECs and PHBs only in a future patch. A new pnv_phb4_get_phb_stack_no() helper is introduced to eliminate most of the stack->stack_no uses we have. The only use left after this patch is during pnv_pec_stk_default_phb_realize() when calculating phb_id, which will also handled in the next patches. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220114180719.52117-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: introduce PnvPHB4 'pec' propertyDaniel Henrique Barboza2022-01-181-6/+13
| | | | | | | | | | | This property will track the owner PEC of this PHB. For now it's redundant since we can retrieve the PEC via phb->stack->pec but it will not be redundant when we get rid of the stack device. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220114180719.52117-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: move phb_regs_mr to PnvPHB4Daniel Henrique Barboza2022-01-181-3/+3
| | | | | | | | | | After recent changes, this MemoryRegion can be migrated to PnvPHB4 without too much trouble. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-11-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: move nest_regs_mr to PnvPHB4Daniel Henrique Barboza2022-01-181-9/+7Star
| | | | | | | | | | | | | | | | | | | | 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>
* ppc/pnv: change pnv_pec_stk_update_map() to use PnvPHB4Daniel Henrique Barboza2022-01-181-3/+3
| | | | | | | | | | | | | | | | 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>
* ppc/pnv: move nest_regs[] to PnvPHB4Daniel Henrique Barboza2022-01-181-25/+27
| | | | | | | | | | | | | | 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>
* ppc/pnv: move mmbar0/mmbar1 and friends to PnvPHB4Daniel Henrique Barboza2022-01-181-26/+26
| | | | | | | | | | | 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>
* ppc/pnv: change pnv_phb4_update_regions() to use PnvPHB4Daniel Henrique Barboza2022-01-181-5/+3Star
| | | | | | | | | | 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>
* ppc/pnv: move intbar to PnvPHB4Daniel Henrique Barboza2022-01-181-9/+9
| | | | | | | | | 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>
* ppc/pnv: move phbbar to PnvPHB4Daniel Henrique Barboza2022-01-181-9/+10
| | | | | | | | | | | | | 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>
* ppc/pnv: move PCI registers to PnvPHB4Daniel Henrique Barboza2022-01-181-15/+15
| | | | | | | | | | | | 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>
* ppc/pnv: use PHB4 obj in pnv_pec_stk_pci_xscom_opsDaniel Henrique Barboza2022-01-181-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ppc/pnv: use stack->pci_regs[] in pnv_pec_stk_pci_xscom_write()Daniel Henrique Barboza2022-01-121-10/+10
| | | | | | | | | | | | | | | | | | | | 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>
* ppc/pnv: turn pnv_phb4_update_regions() into staticDaniel Henrique Barboza2022-01-121-26/+26
| | | | | | | | | 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>
* ppc/pnv: Introduce user creatable pnv-phb4 devicesDaniel Henrique Barboza2022-01-121-2/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ppc/pnv: turn 'phb' into a pointer in struct PnvPhb4PecStackDaniel Henrique Barboza2022-01-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ppc/pnv: move PHB4 XSCOM init to phb4_realize()Daniel Henrique Barboza2022-01-121-0/+304
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.cDaniel Henrique Barboza2022-01-121-0/+17
| | | | | | | | | | | | | | | | 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>
* pnv_phb4.c: check if root port exists in rc_config functionsDaniel Henrique Barboza2022-01-121-2/+8
| | | | | | | | | | | | | 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>
* pnv_phb4.c: make pnv-phb4-root-port user creatableDaniel Henrique Barboza2022-01-121-11/+7Star
| | | | | | | | | | | | | | | 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>
* pnv_phb4.c: add unique chassis and slot for pnv_phb4_root_portDaniel Henrique Barboza2022-01-121-0/+15
| | | | | | | | | | | 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>
* pnv_phb4.c: do not set 'root-bus' as bus nameDaniel Henrique Barboza2022-01-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ppc/pnv: Remove the PHB4 "device-id" propertyCédric Le Goater2022-01-041-1/+0Star
| | | | | | | | | 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>
* ppc/pnv: Remove PHB4 reset handlerCédric Le Goater2022-01-041-13/+0Star
| | | | | | | | | | | | | | 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>
* dma: Let dma_memory_read/write() take MemTxAttrs argumentPhilippe Mathieu-Daudé2021-12-301-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pci-host: Allow extended config space access for PowerNV PHB4 modelChristophe Lombard2021-12-171-0/+1
| | | | | | | | | | | | | | 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>
* hw/pci-hist/pnv_phb4: Fix typo in pnv_phb4_ioda_writeRichard Henderson2021-07-261-1/+1
| | | | | | | | | | | | | | 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>
* ppc/pnv: Add trace events for PCI event notificationCédric Le Goater2021-02-101-0/+3
| | | | | | | | | | On POWER9 systems, PHB controllers signal the XIVE interrupt controller of a source interrupt notification using a store on a MMIO region. Add traces for such events. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210126171059.307867-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* hw/pci-host: Use the PCI_BUILD_BDF() macro from 'hw/pci/pci.h'Philippe Mathieu-Daudé2021-01-041-1/+1
| | | | | | | | | | We already have a generic PCI_BUILD_BDF() macro in "hw/pci/pci.h" to pack these values, use it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20201012124506.3406909-3-philmd@redhat.com>
* Use DECLARE_*CHECKER* macrosEduardo Habkost2020-09-091-2/+2
| | | | | | | | | | | | | | | Generated using: $ ./scripts/codeconverter/converter.py -i \ --pattern=TypeCheckMacro $(git grep -l '' -- '*.[ch]') Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-12-ehabkost@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-13-ehabkost@redhat.com> Message-Id: <20200831210740.126168-14-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* Move QOM typedefs and add missing includesEduardo Habkost2020-09-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some typedefs and macros are defined after the type check macros. This makes it difficult to automatically replace their definitions with OBJECT_DECLARE_TYPE. Patch generated using: $ ./scripts/codeconverter/converter.py -i \ --pattern=QOMStructTypedefSplit $(git grep -l '' -- '*.[ch]') which will split "typdef struct { ... } TypedefName" declarations. Followed by: $ ./scripts/codeconverter/converter.py -i --pattern=MoveSymbols \ $(git grep -l '' -- '*.[ch]') which will: - move the typedefs and #defines above the type check macros - add missing #include "qom/object.h" lines if necessary Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-9-ehabkost@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-10-ehabkost@redhat.com> Message-Id: <20200831210740.126168-11-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* error: Eliminate error_propagate() with Coccinelle, part 1Markus Armbruster2020-07-101-3/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When all we do with an Error we receive into a local variable is propagating to somewhere else, we can just as well receive it there right away. Convert if (!foo(..., &err)) { ... error_propagate(errp, err); ... return ... } to if (!foo(..., errp)) { ... ... return ... } where nothing else needs @err. Coccinelle script: @rule1 forall@ identifier fun, err, errp, lbl; expression list args, args2; binary operator op; constant c1, c2; symbol false; @@ if ( ( - fun(args, &err, args2) + fun(args, errp, args2) | - !fun(args, &err, args2) + !fun(args, errp, args2) | - fun(args, &err, args2) op c1 + fun(args, errp, args2) op c1 ) ) { ... when != err when != lbl: when strict - error_propagate(errp, err); ... when != err ( return; | return c2; | return false; ) } @rule2 forall@ identifier fun, err, errp, lbl; expression list args, args2; expression var; binary operator op; constant c1, c2; symbol false; @@ - var = fun(args, &err, args2); + var = fun(args, errp, args2); ... when != err if ( ( var | !var | var op c1 ) ) { ... when != err when != lbl: when strict - error_propagate(errp, err); ... when != err ( return; | return c2; | return false; | return var; ) } @depends on rule1 || rule2@ identifier err; @@ - Error *err = NULL; ... when != err Not exactly elegant, I'm afraid. The "when != lbl:" is necessary to avoid transforming if (fun(args, &err)) { goto out } ... out: error_propagate(errp, err); even though other paths to label out still need the error_propagate(). For an actual example, see sclp_realize(). Without the "when strict", Coccinelle transforms vfio_msix_setup(), incorrectly. I don't know what exactly "when strict" does, only that it helps here. The match of return is narrower than what I want, but I can't figure out how to express "return where the operand doesn't use @err". For an example where it's too narrow, see vfio_intx_enable(). Silently fails to convert hw/arm/armsse.c, because Coccinelle gets confused by ARMSSE being used both as typedef and function-like macro there. Converted manually. Line breaks tidied up manually. One nested declaration of @local_err deleted manually. Preexisting unwanted blank line dropped in hw/riscv/sifive_e.c. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200707160613.848843-35-armbru@redhat.com>
* qom: Put name parameter before value / visitor parameterMarkus Armbruster2020-07-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The object_property_set_FOO() setters take property name and value in an unusual order: void object_property_set_FOO(Object *obj, FOO_TYPE value, const char *name, Error **errp) Having to pass value before name feels grating. Swap them. Same for object_property_set(), object_property_get(), and object_property_parse(). Convert callers with this Coccinelle script: @@ identifier fun = { object_property_get, object_property_parse, object_property_set_str, object_property_set_link, object_property_set_bool, object_property_set_int, object_property_set_uint, object_property_set, object_property_set_qobject }; expression obj, v, name, errp; @@ - fun(obj, v, name, errp) + fun(obj, name, v, errp) Chokes on hw/arm/musicpal.c's lcd_refresh() with the unhelpful error message "no position information". Convert that one manually. Fails to convert hw/arm/armsse.c, because Coccinelle gets confused by ARMSSE being used both as typedef and function-like macro there. Convert manually. Fails to convert hw/rx/rx-gdbsim.c, because Coccinelle gets confused by RXCPU being used both as typedef and function-like macro there. Convert manually. The other files using RXCPU that way don't need conversion. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200707160613.848843-27-armbru@redhat.com> [Straightforwad conflict with commit 2336172d9b "audio: set default value for pcspk.iobase property" resolved]
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2025-01-16 01:16:04 +0100