aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2019-12-17ppc/pnv: add a PSI bridge model for POWER10Cédric Le Goater2-8/+44
The POWER10 PSIHB controller is very similar to the one on POWER9. We should probably introduce a common PnvPsiXive object. The ESB page size should be changed to 64k when P10 support is ready. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191205184454.10722-5-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/psi: cleanup definitionsCédric Le Goater1-2/+5
Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191205184454.10722-4-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Introduce a POWER10 PnvChip and a powernv10 machineCédric Le Goater3-11/+180
This is an empty shell with the XSCOM bus and cores. The chip controllers will come later. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191205184454.10722-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc: Don't use CPUPPCState::irq_input_state with modern Book3s CPU modelsGreg Kurz1-14/+2
The power7_set_irq() and power9_set_irq() functions set this but it is never used actually. Modern Book3s compatible CPUs are only supported by the pnv and spapr machines. They have an interrupt controller, XICS for POWER7/8 and XIVE for POWER9, whose models don't require to track IRQ input states at the CPU level. Drop these lines to avoid confusion. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157548862861.3650476.16622818876928044450.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17xics: Don't deassert outputsGreg Kurz1-3/+0
The correct way to do this is to deassert the input pins on the CPU side. This is the case since a previous change. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157548862298.3650476.1228720391270249433.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc: Deassert the external interrupt pin in KVM on resetGreg Kurz1-0/+8
When a CPU is reset, QEMU makes sure no interrupt is pending by clearing CPUPPCstate::pending_interrupts in ppc_cpu_reset(). In the case of a complete machine emulation, eg. a sPAPR machine, an external interrupt request could still be pending in KVM though, eg. an IPI. It will be eventually presented to the guest, which is supposed to acknowledge it at the interrupt controller. If the interrupt controller is emulated in QEMU, either XICS or XIVE, ppc_set_irq() won't deassert the external interrupt pin in KVM since it isn't pending anymore for QEMU. When the vCPU re-enters the guest, the interrupt request is still pending and the vCPU will try again to acknowledge it. This causes an infinite loop and eventually hangs the guest. The code has been broken since the beginning. The issue wasn't hit before because accel=kvm,kernel-irqchip=off is an awkward setup that never got used until recently with the LC92x IBM systems (aka, Boston). Add a ppc_irq_reset() function to do the necessary cleanup, ie. deassert the IRQ pins of the CPU in QEMU and most importantly the external interrupt pin for this vCPU in KVM. Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157548861740.3650476.16879693165328764758.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17spapr: Simplify ovec diffDavid Gibson3-37/+15
spapr_ovec_diff(ov, old, new) has somewhat complex semantics. ov is set to those bits which are in new but not old, and it returns as a boolean whether or not there are any bits in old but not new. It turns out that both callers only care about the second, not the first. This is basically equivalent to a bitmap subset operation, which is easier to understand and implement. So replace spapr_ovec_diff() with spapr_ovec_subset(). Cc: Mike Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cedric Le Goater <clg@fr.ibm.com>
2019-12-17spapr: Fold h_cas_compose_response() into h_client_architecture_support()David Gibson2-63/+53
spapr_h_cas_compose_response() handles the last piece of the PAPR feature negotiation process invoked via the ibm,client-architecture-support OF call. Its only caller is h_client_architecture_support() which handles most of the rest of that process. I believe it was placed in a separate file originally to handle some fiddly dependencies between functions, but mostly it's just confusing to have the CAS process split into two pieces like this. Now that compose response is simplified (by just generating the whole device tree anew), it's cleaner to just fold it into h_client_architecture_support(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cedric Le Goater <clg@fr.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org>
2019-12-17spapr: Improve handling of fdt buffer sizeDavid Gibson1-22/+11
Previously, spapr_build_fdt() constructed the device tree in a fixed buffer of size FDT_MAX_SIZE. This is a bit inflexible, but more importantly it's awkward for the case where we use it during CAS. In that case the guest firmware supplies a buffer and we have to awkwardly check that what we generated fits into it afterwards, after doing a lot of size checks during spapr_build_fdt(). Simplify this by having spapr_build_fdt() take a 'space' parameter. For the CAS case, we pass in the buffer size provided by SLOF, for the machine init case, we continue to pass FDT_MAX_SIZE. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cedric Le Goater <clg@fr.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org>
2019-12-17spapr: Don't trigger a CAS reboot for XICS/XIVE mode changeoverDavid Gibson1-20/+13
PAPR allows the interrupt controller used on a POWER9 machine (XICS or XIVE) to be selected by the guest operating system, by using the ibm,client-architecture-support (CAS) feature negotiation call. Currently, if the guest selects an interrupt controller different from the one selected at initial boot, this causes the system to be reset with the new model and the boot starts again. This means we run through the SLOF boot process twice, as well as any other bootloader (e.g. grub) in use before the OS calls CAS. This can be confusing and/or inconvenient for users. Thanks to two fairly recent changes, we no longer need this reboot. 1) we now completely regenerate the device tree when CAS is called (meaning we don't need special case updates for all the device tree changes caused by the interrupt controller mode change), 2) we now have explicit code paths to activate and deactivate the different interrupt controllers, rather than just implicitly calling those at machine reset time. We can therefore eliminate the reboot for changing irq mode, simply by putting a call to spapr_irq_update_active_intc() before we call spapr_h_cas_compose_response() (which gives the updated device tree to the guest firmware and OS). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cedric Le Goater <clg@fr.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org>
2019-12-17ppc: well form kvmppc_hint_smt_possible error hint helperVladimir Sementsov-Ogievskiy1-1/+1
Make kvmppc_hint_smt_possible hint append helper well formed: rename errp to errp_in, as it is IN-parameter here (which is unusual for errp), rename function to be kvmppc_error_append_*_hint. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20191127191434.20945-1-vsementsov@virtuozzo.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Dump the XIVE NVT tableCédric Le Goater1-0/+64
This is useful to dump the saved contexts of the vCPUs : configuration of the base END index of the vCPU and the Interrupt Pending Buffer register, which is updated when an interrupt can not be presented. When dumping the NVT table, we skip empty indirect pages which are not necessarily allocated. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-21-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Extend XiveRouter with a get_block_id() handlerCédric Le Goater3-5/+28
When doing CAM line compares, fetch the block id from the interrupt controller which can have set the PC_TCTXT_CHIPID field. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-20-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Introduce a pnv_xive_block_id() helperCédric Le Goater1-31/+33
When PC_TCTXT_CHIPID_OVERRIDE is configured, the PC_TCTXT_CHIPID field overrides the hardwired chip ID in the Powerbus operations and for CAM compares. This is typically used in the one block-per-chip configuration to associate a unique block id number to each IC of the system. Simplify the model with a pnv_xive_block_id() helper and remove 'tctx_chipid' which becomes useless. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-19-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Synthesize interrupt from the saved IPB in the NVTCédric Le Goater1-0/+52
When a vCPU is dispatched on a HW thread, its context is pushed in the thread registers and it is activated by setting the VO bit in the CAM line word2. The HW grabs the associated NVT, pulls the IPB bits and merges them with the IPB of the new context. If interrupts were missed while the vCPU was not dispatched, these are synthesized in this sequence. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-18-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Introduce a xive_tctx_ipb_update() helperCédric Le Goater1-10/+11
We will use it to resend missed interrupts when a vCPU context is pushed on a HW thread. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-17-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Remove the get_tctx() XiveRouter handlerCédric Le Goater3-28/+0
It is now unused. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-16-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Move the TIMA operations to the controller modelCédric Le Goater3-32/+65
On the P9 Processor, the thread interrupt context registers of a CPU can be accessed "directly" when by load/store from the CPU or "indirectly" by the IC through an indirect TIMA page. This requires to configure first the PC_TCTXT_INDIRx registers. Today, we rely on the get_tctx() handler to deduce from the CPU PIR the chip from which the TIMA access is being done. By handling the TIMA memory ops under the interrupt controller model of each machine, we can uniformize the TIMA direct and indirect ops under PowerNV. We can also check that the CPUs have been enabled in the XIVE controller. This prepares ground for the future versions of XIVE. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-15-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Clarify how the TIMA is accessed on a multichip systemCédric Le Goater2-17/+37
The TIMA region gives access to the thread interrupt context registers of a CPU. It is mapped at the same address on all chips and can be accessed by any CPU of the system. To identify the chip from which the access is being done, the PowerBUS uses a 'chip' field in the load/store messages. QEMU does not model these messages, instead, we extract the chip id from the CPU PIR and do a lookup at the machine level to fetch the targeted interrupt controller. Introduce pnv_get_chip() and pnv_xive_tm_get_xive() helpers to clarify this process in pnv_xive_get_tctx(). The latter will be removed in the subsequent patches but the same principle will be kept. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-14-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17spapr/xive: Configure number of servers in KVMGreg Kurz1-2/+21
The XIVE KVM devices now has an attribute to configure the number of interrupt servers. This allows to greatly optimize the usage of the VP space in the XIVE HW, and thus to start a lot more VMs. Only set this attribute if available in order to support older POWER9 KVM. The XIVE KVM device now reports the exhaustion of VPs upon the connection of the first VCPU. Check that in order to have a chance to provide a hint to the user. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157478679392.67101.7843580591407950866.stgit@bahia.tlslab.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17spapr/xics: Configure number of servers in KVMGreg Kurz1-2/+19
The XICS-on-XIVE KVM devices now has an attribute to configure the number of interrupt servers. This allows to greatly optimize the usage of the VP space in the XIVE HW, and thus to start a lot more VMs. Only set this attribute if available in order to support older POWER9 KVM and pre-POWER9 XICS KVM devices. The XICS-on-XIVE KVM device now reports the exhaustion of VPs upon the connection of the first VCPU. Check that in order to have a chance to provide a hint to the user. ` Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157478678846.67101.9660531022460517710.stgit@bahia.tlslab.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17spapr: Pass the maximum number of vCPUs to the KVM interrupt controllerGreg Kurz5-9/+16
The XIVE and XICS-on-XIVE KVM devices on POWER9 hosts can greatly reduce their consumption of some scarce HW resources, namely Virtual Presenter identifiers, if they know the maximum number of vCPUs that may run in the VM. Prepare ground for this by passing the value down to xics_kvm_connect() and kvmppc_xive_connect(). This is purely mechanical, no functional change. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157478678301.67101.2717368060417156338.stgit@bahia.tlslab.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Extend the TIMA operation with a XivePresenter parameterCédric Le Goater2-28/+34
The TIMA operations are performed on behalf of the XIVE IVPE sub-engine (Presenter) on the thread interrupt context registers. The current operations supported by the model are simple and do not require access to the controller but more complex operations will need access to the controller NVT table and to its configuration. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-13-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Use the XiveFabric and XivePresenter interfacesCédric Le Goater1-31/+17
Now that the machines have handlers implementing the XiveFabric and XivePresenter interfaces, remove xive_presenter_match() and make use of the 'match_nvt' handler of the machine. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-12-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/spapr: Implement the XiveFabric interfaceCédric Le Goater1-0/+39
The CAM line matching sequence in the pseries machine does not change much apart from the use of the new QOM interfaces. There is an extra indirection because of the sPAPR IRQ backend of the machine. Only the XIVE backend implements the new 'match_nvt' handler. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-11-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Implement the XiveFabric interfaceCédric Le Goater1-0/+35
The CAM line matching on the PowerNV machine now scans all chips of the system and all CPUs of a chip to find a dispatched NVT in the thread contexts. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-10-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Introduce a XiveFabric interfaceCédric Le Goater1-0/+10
The XiveFabric QOM interface acts as the PowerBUS interface between the interrupt controller and the system and should be implemented by the QEMU machine. On HW, the XIVE sub-engine is responsible for the communication with the other chip is the Common Queue (CQ) bridge unit. This interface offers a 'match_nvt' handler to perform the CAM line matching when looking for a XIVE Presenter with a dispatched NVT. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-9-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Fix TIMA indirect accessCédric Le Goater2-6/+24
When the TIMA of a CPU needs to be accessed from the indirect page, the thread id of the target CPU is first stored in the PC_TCTXT_INDIR0 register. This thread id is relative to the chip and not to the system. Introduce a helper routine to look for a CPU of a given PIR and fix pnv_xive_get_indirect_tctx() to scan only the threads of the local chip and not the whole machine. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-8-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Introduce a pnv_xive_is_cpu_enabled() helperCédric Le Goater1-0/+19
and use this helper to exclude CPUs which are not enabled in the XIVE controller. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-7-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc: Introduce a ppc_cpu_pir() helperCédric Le Goater1-2/+7
Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-6-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Loop on the threads of the chip to find a matching NVTCédric Le Goater1-26/+35
CPU_FOREACH() loops on all the CPUs of the machine which is incorrect. Each XIVE Presenter should scan only the HW threads of the chip it belongs to. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-5-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Instantiate cores separatelyGreg Kurz1-18/+12
Allocating a big void * array to store multiple objects isn't a recommended practice for various reasons: - no compile time type checking - potential dangling pointers if a reference on an individual is taken and the array is freed later on - duplicate boiler plate everywhere the array is browsed through Allocate an array of pointers and populate it instead. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-4-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Implement the XivePresenter interfaceCédric Le Goater3-44/+97
Each XIVE Router model, sPAPR and PowerNV, now implements the 'match_nvt' handler of the XivePresenter QOM interface. This is simply moving code and taking into account the new API. To be noted that the xive_router_get_tctx() helper is not used anymore when doing CAM matching and will be removed later on after other changes. The XIVE presenter model is still too simple for the PowerNV machine and the CAM matching algo is not correct on multichip system. Subsequent patches will introduce more changes to scan all chips of the system. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Introduce a XivePresenter interfaceCédric Le Goater1-9/+17
When the XIVE IVRE sub-engine (XiveRouter) looks for a Notification Virtual Target (NVT) to notify, it broadcasts a message on the PowerBUS to find an XIVE IVPE sub-engine (Presenter) with the NVT dispatched on one of its HW threads, and then forwards the notification if any response was received. The current XIVE presenter model is sufficient for the pseries machine because it has a single interrupt controller device, but the PowerNV machine can have multiple chips each having its own interrupt controller. In this case, the XIVE presenter model is too simple and the CAM line matching should scan all chips of the system. To start fixing this issue, we first extend the XIVE Router model with a new XivePresenter QOM interface representing the XIVE IVPE sub-engine. This interface exposes a 'match_nvt' handler which the sPAPR and PowerNV XIVE Router models will need to implement to perform the CAM line matching. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Create BMC devices at machine initCédric Le Goater2-20/+33
The BMC of the OpenPOWER systems monitors the machine state using sensors, controls the power and controls the access to the PNOR flash device containing the firmware image required to boot the host. QEMU models the power cycle process, access to the sensors and access to the PNOR device. But, for these features to be available, the QEMU PowerNV machine needs two extras devices on the command line, an IPMI BT device for communication and a BMC backend device: -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-bt,bmc=bmc0,irq=10 The BMC properties are then defined accordingly in the device tree and OPAL self adapts. If a BMC device and an IPMI BT device are not available, OPAL does not try to communicate with the BMC in any manner. This is not how real systems behave. To be closer to the default behavior, create an IPMI BMC simulator device and an IPMI BT device at machine initialization time. We loose the ability to define an external BMC device but there are benefits: - a better match with real systems, - a better test coverage of the OPAL code, - system powerdown and reset commands that work, - a QEMU device tree compliant with the specifications (*). (*) Still needs a MBOX device. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191121162340.11049-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Add HIOMAP commandsCédric Le Goater3-0/+116
This activates HIOMAP support on the QEMU PowerNV machine. The PnvPnor model is used to access the flash contents. The model simply maps the contents at a fix offset and enables or disables the mapping. HIOMAP Protocol description : https://github.com/openbmc/hiomapd/blob/master/Documentation/protocol.md Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191028070027.22752-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ipmi: Add support to customize OEM functionsCédric Le Goater1-44/+6
The routine ipmi_register_oem_netfn() lets external modules register command handlers for OEM functions. Required for the PowerNV machine. Cc: Corey Minyard <cminyard@mvista.com> Reviewed-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191028070027.22752-2-clg@kaod.org> Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Check V bit in TM_PULL_POOL_CTXCédric Le Goater1-0/+5
A context should be 'valid' when pulled from the thread interrupt context registers. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191115162436.30548-8-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Introduce OS CAM line helpersCédric Le Goater1-3/+38
The OS CAM line has a special encoding exploited by the HW. Provide helper routines to hide the details to the TIMA command handlers. This also clarifies the endianness of different variables : 'qw1w2' is big-endian and 'cam' is native. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191115162436.30548-7-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Quiesce some XIVE errorsCédric Le Goater1-1/+5
When dumping the END and NVT tables, the error logging is too noisy. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191115162436.30548-6-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17xive/kvm: Trigger interrupts from userspaceGreg Kurz1-14/+2
When using the XIVE KVM device, the trigger page is directly accessible in QEMU. Unlike with XICS, no need to ask KVM to fire the interrupt. A simple store on the trigger page does the job. Just call xive_esb_trigger(). This may improve performance of emulated devices that go through qemu_set_irq(), eg. virtio devices created with ioeventfd=off or configured by the guest to use LSI interrupts, which aren't really recommended setups. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157408992731.494439.3405812941731584740.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Remove pnv_xive_vst_size() routineCédric Le Goater1-69/+43
pnv_xive_vst_size() tries to compute the size of a VSD table from the information given by FW. The number of entries of the table are deduced from the result and the MMIO regions of the ESBs and the END ESBs are then resized accordingly with the computed value. This reduces the number of elements that can be addressed by the ESB pages. The maximum number of elements of a direct table can contain is simply: Table size / sizeof(XIVE structure) An indirect table is a one page array of VSDs pointing to subpages containing XIVE virtual structures and the maximum number of elements an indirect table can contain : (PAGE_SIZE / sizeof(vsd)) * (PAGE_SIZE / sizeof(XIVE structure)) which gives us 16M for XiveENDs, 8M for XiveNVTs. That's more than the associated VC and PC BARS can address. The result returned by pnv_xive_vst_size() for indirect tables is incorrect and can not be used to reduce the size of the MMIO region of a XIVE resource using an indirect table, such as ENDs in skiboot. Remove pnv_xive_vst_size() and use a simpler form for direct tables only. Keep the resizing of the MMIO region for direct tables only as this is still useful for the ESB MMIO window. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191115162436.30548-4-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/xive: Record the IPB in the associated NVTCédric Le Goater1-2/+9
When an interrupt can not be presented to a vCPU, because it is not running on any of the HW treads, the XIVE presenter updates the Interrupt Pending Buffer register of the associated XIVE NVT structure. This is only done if backlog is activated in the END but this is generally the case. The current code assumes that the fields of the NVT structure is architected with the same layout of the thread interrupt context registers. Fix this assumption and define an offset for the IPB register backup value in the NVT. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191115162436.30548-2-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Add a LPC "ranges" propertyCédric Le Goater1-1/+13
And fix a typo in the MEM address space definition. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191118091908.15044-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17spapr: Abort if XICS interrupt controller cannot be initializedGreg Kurz1-11/+2
Failing to set any of the ICS property should really never happen: - object_property_add_child() always succeed unless the child object already has a parent, which isn't the case here obviously since the ICS has just been created with object_new() - the ICS has an "nr-irqs" property than can be set as long as the ICS isn't realized In both cases, an error indicates there is a bug in QEMU. Propagating the error, ie. exiting QEMU since spapr_irq_init() is called with &error_fatal doesn't make much sense. Abort instead. This is consistent with what is done with XIVE : both qdev_create() and qdev_prop_set_uint32() abort QEMU on error. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157403285265.409804.8683093665795248192.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17xics: Link ICP_PROP_CPU property to ICPState::cs pointerGreg Kurz1-17/+4
The ICP object has both a pointer and an ICP_PROP_CPU property pointing to the cpu. Confusing bugs could arise if these ever go out of sync. Change the property definition so that it explicitly sets the pointer. The property isn't optional : not being able to set the link is a bug and QEMU should rather abort than exit in this case. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157403284709.409804.16142099083325945141.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17xics: Link ICP_PROP_XICS property to ICPState::xics pointerGreg Kurz1-13/+9
The ICP object has both a pointer and an ICP_PROP_XICS property pointing to the XICS fabric. Confusing bugs could arise if these ever go out of sync. Change the property definition so that it explicitly sets the pointer. The property isn't optional : not being able to set the link is a bug and QEMU should rather abort than exit in this case. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157403284152.409804.17114564311521923733.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17xics: Link ICS_PROP_XICS property to ICSState::xics pointerGreg Kurz3-19/+6
The ICS object has both a pointer and an ICS_PROP_XICS property pointing to the XICS fabric. Confusing bugs could arise if these ever go out of sync. Change the property definition so that it explicitely sets the pointer. The property isn't optional : not being able to set the link is a bug and QEMU should rather abort than exit in this case. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157403283596.409804.17347207690271971987.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Link "chip" property to PnvXive::chip pointerGreg Kurz2-12/+5
The XIVE object has both a pointer and a "chip" property pointing to the chip object. Confusing bugs could arise if these ever go out of sync. Change the property definition so that it explicitely sets the pointer. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157383336564.165747.10250365296928442882.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-12-17ppc/pnv: Link "chip" property to PnvCore::chip pointerGreg Kurz2-10/+4
The core object has both a pointer and a "chip" property pointing to the chip object. Confusing bugs could arise if these ever go out of sync. Change the property definition so that it explicitely sets the pointer. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157383336007.165747.1524120147081367440.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
generated by cgit v1.1 at 2024-08-23 12:59:08 +0000