summaryrefslogtreecommitdiffstats
path: root/include/hw/ppc/spapr_irq.h
Commit message (Collapse)AuthorAgeFilesLines
* spapr: Pass the maximum number of vCPUs to the KVM interrupt controllerGreg Kurz2019-12-171-2/+8
| | | | | | | | | | | | | | | | 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>
* ppc: Add intc_destroy() handlers to SpaprInterruptController/PnvChipGreg Kurz2019-11-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | SpaprInterruptControllerClass and PnvChipClass have an intc_create() method that calls the appropriate routine, ie. icp_create() or xive_tctx_create(), to establish the link between the VCPU and the presenter component of the interrupt controller during realize. There aren't any symmetrical call to be called when the VCPU gets unrealized though. It is assumed that object_unparent() is the only thing to do. This is questionable because the parenting logic around the CPU and presenter objects is really an implementation detail of the interrupt controller. It shouldn't be open-coded in the machine code. Fix this by adding an intc_destroy() method that undoes what was done in intc_create(). Also NULLify the presenter pointers to avoid having stale pointers around. This will allow to reliably check if a vCPU has a valid presenter. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157192724208.3146912.7254684777515287626.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
* ppc: Reset the interrupt presenter from the CPU reset handlerCédric Le Goater2019-10-241-0/+2
| | | | | | | | | | | | | | | | | | | | | On the sPAPR machine and PowerNV machine, the interrupt presenters are created by a machine handler at the core level and are reset independently. This is not consistent and it raises issues when it comes to handle hot-plugged CPUs. In that case, the presenters are not reset. This is less of an issue in XICS, although a zero MFFR could be a concern, but in XIVE, the OS CAM line is not set and this breaks the presenting algorithm. The current code has workarounds which need a global cleanup. Extend the sPAPR IRQ backend and the PowerNV Chip class with a new cpu_intc_reset() handler called by the CPU reset handler and remove the XiveTCTX reset handler which is now redundant. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191022163812.330-6-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Move SpaprIrq::nr_xirqs to SpaprMachineClassDavid Gibson2019-10-241-1/+0Star
| | | | | | | | | | | | | | | | | For the benefit of peripheral device allocation, the number of available irqs really wants to be the same on a given machine type version, regardless of what irq backends we are using. That's the case now, but only because we make sure the different SpaprIrq instances have the same value except for the special legacy one. Since this really only depends on machine type version, move the value to SpaprMachineClass instead of SpaprIrq. This also puts the code to set it to the lower value on old machine types right next to setting legacy_irq_allocation, which needs to go hand in hand. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr: Remove SpaprIrq::nr_msisDavid Gibson2019-10-241-3/+1Star
| | | | | | | | | | | The nr_msis value we use here has to line up with whether we're using legacy or modern irq allocation. Therefore it's safer to derive it based on legacy_irq_allocation rather than having SpaprIrq contain a canned value. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr, xics, xive: Move SpaprIrq::post_load hook to backendsDavid Gibson2019-10-241-2/+1Star
| | | | | | | | | | | The remaining logic in the post_load hook really belongs to the interrupt controller backends, and just needs to be called on the active controller (after the active controller is set to the right thing based on the incoming migration in the generic spapr_irq_post_load() logic). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr, xics, xive: Move SpaprIrq::reset hook logic into activate/deactivateDavid Gibson2019-10-241-1/+3
| | | | | | | | | | | | | | | | It turns out that all the logic in the SpaprIrq::reset hooks (and some in the SpaprIrq::post_load hooks) isn't really related to resetting the irq backend (that's handled by the backends' own reset routines). Rather its about getting the backend ready to be the active interrupt controller or stopping being the active interrupt controller - reset (and post_load) is just the only time that changes at present. To make this flow clearer, move the logic into the explicit backend activate and deactivate hooks. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr: Remove SpaprIrq::init_kvm hookDavid Gibson2019-10-241-1/+0Star
| | | | | | | | | | | | | | | | | This hook is a bit odd. The only caller is spapr_irq_init_kvm(), but it explicitly takes an SpaprIrq *, so it's never really called through the current SpaprIrq. Essentially this is just a way of passing through a function pointer so that spapr_irq_init_kvm() can handle some configuration and error handling logic without duplicating it between the xics and xive reset paths. So, make it just take that function pointer. Because of earlier reworks to the KVM connect/disconnect code in the xics and xive backends we can also eliminate some wrapper functions and streamline error handling a bit. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr, xics, xive: Move dt_populate from SpaprIrq to SpaprInterruptControllerDavid Gibson2019-10-241-2/+4
| | | | | | | | | | | This method depends only on the active irq controller. Now that we've formalized the notion of active controller we can dispatch directly through that, rather than dispatching via SpaprIrq with the dual version having to do a second conditional dispatch. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr, xics, xive: Move print_info from SpaprIrq to SpaprInterruptControllerDavid Gibson2019-10-241-2/+2
| | | | | | | | | | | This method depends only on the active irq controller. Now that we've formalized the notion of active controller we can dispatch directly through that, rather than dispatching via SpaprIrq with the dual version having to do a second conditional dispatch. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr, xics, xive: Move set_irq from SpaprIrq to SpaprInterruptControllerDavid Gibson2019-10-241-1/+3
| | | | | | | | | | | This method depends only on the active irq controller. Now that we've formalized the notion of active controller we can dispatch directly through that, rather than dispatching via SpaprIrq with the dual version having to do a second conditional dispatch. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr: Formalize notion of active interrupt controllerDavid Gibson2019-10-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | spapr now has the mechanism of constructing both XICS and XIVE instances of the SpaprInterruptController interface. However, only one of the interrupt controllers will actually be active at any given time, depending on feature negotiation with the guest. This is handled in the current code via spapr_irq_current() which checks the OV5 vector from feature negotiation to determine the current backend. Determining the active controller at the point we need it like this can be pretty confusing, because it makes it very non obvious at what points the active controller can change. This can make it difficult to reason about the code and where a change of active controller could appear in sequence with other events. Make this mechanism more explicit by adding an 'active_intc' pointer and an explicit spapr_irq_update_active_intc() function to update it from the CAS state. We also add hooks on the intc backend which will get called when it is activated or deactivated. For now we just introduce the switch and hooks, later patches will actually start using them. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr, xics, xive: Move irq claim and free from SpaprIrq to ↵David Gibson2019-10-241-2/+3
| | | | | | | | | | | | | | SpaprInterruptController These methods, like cpu_intc_create, really belong to the interrupt controller, but need to be called on all possible intcs. Like cpu_intc_create, therefore, make them methods on the intc and always call it for all existing intcs. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr, xics, xive: Move cpu_intc_create from SpaprIrq to ↵David Gibson2019-10-241-2/+11
| | | | | | | | | | | | | | | | | | SpaprInterruptController This method essentially represents code which belongs to the interrupt controller, but needs to be called on all possible intcs, rather than just the currently active one. The "dual" version therefore calls into the xics and xive versions confusingly. Handle this more directly, by making it instead a method on the intc backend, and always calling it on every backend that exists. While we're there, streamline the error reporting a bit. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr, xics, xive: Introduce SpaprInterruptController QOM interfaceDavid Gibson2019-10-241-0/+14
| | | | | | | | | | | | | | | | | | | | | | | The SpaprIrq structure is used to represent ths spapr machine's irq backend. Except that it kind of conflates two concepts: one is the backend proper - a specific interrupt controller that we might or might not be using, the other is the irq configuration which covers the layout of irq space and which interrupt controllers are allowed. This leads to some pretty confusing code paths for the "dual" configuration where its hooks redirect to other SpaprIrq structures depending on the currently active irq controller. To clean this up, we start by introducing a new SpaprInterruptController QOM interface to represent strictly an interrupt controller backend, not counting anything configuration related. We implement this interface in the XICs and XIVE interrupt controllers, and in future we'll move relevant methods from SpaprIrq into it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr: Eliminate SpaprIrq::init hookDavid Gibson2019-10-041-1/+0Star
| | | | | | | | | | | | | | This method is used to set up the interrupt backends for the current configuration. However, this means some confusing redirection between the "dual" mode init and the init hooks for xics only and xive only modes. Since we now have simple flags indicating whether XICS and/or XIVE are supported, it's easier to just open code each initialization directly in spapr_irq_init(). This will also make some future cleanups simpler. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
* spapr: Use less cryptic representation of which irq backends are supportedDavid Gibson2019-10-041-1/+2
| | | | | | | | | | | | | | | | SpaprIrq::ov5 stores the value for a particular byte in PAPR option vector 5 which indicates whether XICS, XIVE or both interrupt controllers are available. As usual for PAPR, the encoding is kind of overly complicated and confusing (though to be fair there are some backwards compat things it has to handle). But to make our internal code clearer, have SpaprIrq encode more directly which backends are available as two booleans, and derive the OV5 value from that at the point we need it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
* spapr: Handle freeing of multiple irqs in frontend onlyDavid Gibson2019-10-041-1/+1
| | | | | | | | | | | spapr_irq_free() can be used to free multiple irqs at once. That's useful for its callers, but there's no need to make the individual backend hooks handle this. We can loop across the irqs in spapr_irq_free() itself and have the hooks just do one at time. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr: Eliminate SpaprIrq:get_nodename methodDavid Gibson2019-10-041-1/+0Star
| | | | | | | | | | | | | | | | | | | | This method is used to determine the name of the irq backend's node in the device tree, so that we can find its phandle (after SLOF may have modified it from the phandle we initially gave it). But, in the two cases the only difference between the node name is the presence of a unit address. Searching for a node name without considering unit address is standard practice for the device tree, and fdt_subnode_offset() will do exactly that, making this method unecessary. While we're there, remove the XICS_NODENAME define. The name "interrupt-controller" is required by PAPR (and IEEE1275), and a bunch of places assume it already. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
* spapr: Simplify spapr_qirq() handlingDavid Gibson2019-10-041-1/+0Star
| | | | | | | | | | | | | | | | | | Currently spapr_qirq(), whic is used to find the qemu_irq for an spapr global irq number, redirects through the SpaprIrq::qirq method. But the array of qemu_irqs is allocated in the PAPR layer, not the backends, and so the method implementations all return the same thing, just differing in the preliminary checks they make. So, we can remove the method, and just implement spapr_qirq() directly, including all the relevant checks in one place. We change all those checks into assert()s as well, since a failure here indicates an error in the calling code. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* spapr: Eliminate nr_irqs parameter to SpaprIrq::initDavid Gibson2019-10-041-1/+1
| | | | | | | | | | | The only reason this parameter was needed was to work around the inconsistent meaning of nr_irqs between xics and xive. Now that we've fixed that, we can consistently use the number directly in the SpaprIrq configuration. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org>
* spapr: Clarify and fix handling of nr_irqsDavid Gibson2019-10-041-7/+12
| | | | | | | | | | | | | | | | | | | | | Both the XICS and XIVE interrupt backends have a "nr-irqs" property, but it means slightly different things. For XICS (or, strictly, the ICS) it indicates the number of "real" external IRQs. Those start at XICS_IRQ_BASE (0x1000) and don't include the special IPI vector. For XIVE, however, it includes the whole IRQ space, including XIVE's many IPI vectors. The spapr code currently doesn't handle this sensibly, with the nr_irqs value in SpaprIrq having different meanings depending on the backend. We fix this by renaming nr_irqs to nr_xirqs and making it always indicate just the number of external irqs, adjusting the value we pass to XIVE accordingly. We also move to using common constants in most of the irq configurations, to make it clearer that the IRQ space looks the same to the guest (and emulated devices), even if the backend is different. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* spapr/irq: Drop spapr_irq_msi_reset()Greg Kurz2019-08-211-1/+0Star
| | | | | | | | | | | | | PHBs already take care of clearing the MSIs from the bitmap during reset or unplug. No need to do this globally from the machine code. Rather add an assert to ensure that PHBs have acted as expected. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <156415228966.1064338.190189424190233355.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> [dwg: Fix crash in qtest case where spapr->irq_map can be NULL at the new assert()] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* Include hw/irq.h a lot lessMarkus Armbruster2019-08-161-1/+0Star
| | | | | | | | | | | | | | | | | | | In my "build everything" tree, changing hw/irq.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). hw/hw.h supposedly includes it for convenience. Several other headers include it just to get qemu_irq and.or qemu_irq_handler. Move the qemu_irq and qemu_irq_handler typedefs from hw/irq.h to qemu/typedefs.h, and then include hw/irq.h only where it's still needed. Touching it now recompiles only some 500 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-13-armbru@redhat.com>
* include: Make headers more self-containedMarkus Armbruster2019-08-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back in 2016, we discussed[1] rules for headers, and these were generally liked: 1. Have a carefully curated header that's included everywhere first. We got that already thanks to Peter: osdep.h. 2. Headers should normally include everything they need beyond osdep.h. If exceptions are needed for some reason, they must be documented in the header. If all that's needed from a header is typedefs, put those into qemu/typedefs.h instead of including the header. 3. Cyclic inclusion is forbidden. This patch gets include/ closer to obeying 2. It's actually extracted from my "[RFC] Baby steps towards saner headers" series[2], which demonstrates a possible path towards checking 2 automatically. It passes the RFC test there. [1] Message-ID: <87h9g8j57d.fsf@blackfin.pond.sub.org> https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg03345.html [2] Message-Id: <20190711122827.18970-1-armbru@redhat.com> https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg02715.html Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-2-armbru@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* spapr/xive: simplify spapr_irq_init_device() to remove the emulated initCédric Le Goater2019-07-021-1/+0Star
| | | | | | | | | | The init_emu() handles are now empty. Remove them and rename spapr_irq_init_device() to spapr_irq_init_kvm(). Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190614165920.12670-3-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr/irq: introduce a spapr_irq_init_device() helperCédric Le Goater2019-05-291-0/+2
| | | | | | | | | | | | | | | | | The way the XICS and the XIVE devices are initialized follows the same pattern. First, try to connect to the KVM device and if not possible fallback on the emulated device, unless a kernel_irqchip is required. The spapr_irq_init_device() routine implements this sequence in generic way using new sPAPR IRQ handlers ->init_emu() and ->init_kvm(). The XIVE init sequence is moved under the associated sPAPR IRQ ->init() handler. This will change again when KVM support is added for the dual interrupt mode. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190513084245.25755-12-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Use CamelCase properlyDavid Gibson2019-03-121-29/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The qemu coding standard is to use CamelCase for type and structure names, and the pseries code follows that... sort of. There are quite a lot of places where we bend the rules in order to preserve the capitalization of internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR". That was a bad idea - it frequently leads to names ending up with hard to read clusters of capital letters, and means they don't catch the eye as type identifiers, which is kind of the point of the CamelCase convention in the first place. In short, keeping type identifiers look like CamelCase is more important than preserving standard capitalization of internal "words". So, this patch renames a heap of spapr internal type names to a more standard CamelCase. In addition to case changes, we also make some other identifier renames: VIOsPAPR* -> SpaprVio* The reverse word ordering was only ever used to mitigate the capital cluster, so revert to the natural ordering. VIOsPAPRVTYDevice -> SpaprVioVty VIOsPAPRVLANDevice -> SpaprVioVlan Brevity, since the "Device" didn't add useful information sPAPRDRConnector -> SpaprDrc sPAPRDRConnectorClass -> SpaprDrcClass Brevity, and makes it clearer this is the same thing as a "DRC" mentioned in many other places in the code This is 100% a mechanical search-and-replace patch. It will, however, conflict with essentially any and all outstanding patches touching the spapr code. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr_irq: Expose the phandle of the interrupt controllerGreg Kurz2019-02-251-0/+1
| | | | | | | | | This will be used by PHB hotplug in order to create the "interrupt-map" property of the PHB node. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155059669374.1466090.12943228478046223856.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: Expose the name of the interrupt controller nodeGreg Kurz2019-02-251-0/+1
| | | | | | | | | | | This will be needed by PHB hotplug in order to access the "phandle" property of the interrupt controller node. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <155059668867.1466090.6339199751719123386.stgit@bahia.lab.toulouse-stg.fr.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr/irq: add an 'nr_irq' parameter to initialize the backend.Cédric Le Goater2019-02-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | When using the 'dual' interrupt mode, the source numbers of both sPAPR IRQ backends are aligned to share a common IRQ number space and to use a similar mapping of the machine qemu_irq array which is indexed by the source number. The XICS IRQ number range initially being [ 0x1000 - 0x2000 ], this requires to change the XICS ICSState offset to 0 and to provision for an extra 4K of source numbers and qemu_irqs which will never be used by the machine when running under the XICS interrupt mode. This is not an optimal solution. Change the init() method to allocate an IRQ number space of the expected size for the XICS sPAPR IRQ backend. It breaks the interrupt signaling when under the 'dual' mode because source numbers have unexpected values but next patch will fix that. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190213210756.27032-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: introduce a new sPAPR IRQ backend supporting XIVE and XICSCédric Le Goater2019-01-081-0/+1
| | | | | | | | | | | | | | | The 'dual' sPAPR IRQ backend supports both interrupt mode, XIVE exploitation mode and the legacy compatibility mode (XICS). both modes are not supported at the same time. The machine starts with the legacy mode and a new interrupt mode can then be negotiated by the CAS process. In this case, the new mode is activated after a reset to take into account the required changes in the machine. These impact the device tree layout, the interrupt presenter object and the exposed MMIO regions in the case of XIVE. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: move the qemu_irq array under the machineCédric Le Goater2019-01-081-0/+1
| | | | | | | | | | The qemu_irq array is now allocated at the machine level using a sPAPR IRQ set_irq handler depending on the chosen interrupt mode. The use of this handler is slightly inefficient today but it will become necessary when the 'dual' interrupt mode is introduced. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: modify the prototype of the cpu_intc_create() methodCédric Le Goater2019-01-081-2/+2
| | | | | | | | | | | | | | | | | | Today, the interrupt presenter is linked to a CPU using the cpu_intc_create() method of the sPAPR IRQ backend. The resulting object is assigned to the PowerPCCPU 'intc' pointer whatever the interrupt mode, XICS or XIVE. To support the 'dual' interrupt mode, we will need to distinguish between the two presenter objects and for that, we plan to introduce a second interrupt presenter object pointer under the PowerPCCPU. The modifications below move the assignment of the presenter object under the cpu_intc_create() method to prepare ground for the future changes. Both sPAPR and PowerNV machines are impacted. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: add an extra OV5 field to the sPAPR IRQ backendCédric Le Goater2018-12-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The interrupt modes supported by the hypervisor are advertised to the guest with new bits definitions of the option vector 5 of property "ibm,arch-vec-5-platform-support. The byte 23 bits 0-1 of the OV5 are defined as follow : 0b00 PAPR 2.7 and earlier (Legacy systems) 0b01 XIVE Exploitation mode only 0b10 Either available If the client/guest selects the XIVE interrupt mode, it informs the hypervisor by returning the value 0b01 in byte 23 bits 0-1. A 0b00 value indicates the use of the XICS interrupt mode (Legacy systems). The sPAPR IRQ backend is extended with these definitions and the values are directly used to populate the "ibm,arch-vec-5-platform-support" property. The interrupt mode is advertised under TCG and under KVM. Although a KVM XIVE device is not yet available, the machine can still operate with kernel_irqchip=off. However, we apply a restriction on the CPU which is required to be a POWER9 when a XIVE interrupt controller is in use. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: add a 'reset' method to the sPAPR IRQ backendCédric Le Goater2018-12-201-0/+2
| | | | | | | | | | | | | | | | For the time being, the XIVE reset handler updates the OS CAM line of the vCPU as it is done under a real hypervisor when a vCPU is scheduled to run on a HW thread. This will let the XIVE presenter engine find a match among the NVTs dispatched on the HW threads. This handler will become even more useful when we introduce the machine supporting both interrupt modes, XIVE and XICS. In this machine, the interrupt mode is chosen by the CAS negotiation process and activated after a reset. Signed-off-by: Cédric Le Goater <clg@kaod.org> [dwg: Fix style nits] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: extend the sPAPR IRQ backend for XICS migrationCédric Le Goater2018-12-201-0/+2
| | | | | | | | | Introduce a new sPAPR IRQ handler to handle resend after migration when the machine is using a KVM XICS interrupt controller model. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: allocate the interrupt thread context under the CPU coreCédric Le Goater2018-12-201-0/+2
| | | | | | | | | | | Each interrupt mode has its own specific interrupt presenter object, that we store under the CPU object, one for XICS and one for XIVE. Extend the sPAPR IRQ backend with a new handler to support them both. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: add device tree support for the XIVE exploitation modeCédric Le Goater2018-12-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The XIVE interface for the guest is described in the device tree under the "interrupt-controller" node. A couple of new properties are specific to XIVE : - "reg" contains the base address and size of the thread interrupt managnement areas (TIMA), for the User level and for the Guest OS level. Only the Guest OS level is taken into account today. - "ibm,xive-eq-sizes" the size of the event queues. One cell per size supported, contains log2 of size, in ascending order. - "ibm,xive-lisn-ranges" the IRQ interrupt number ranges assigned to the guest for the IPIs. and also under the root node : - "ibm,plat-res-int-priorities" contains a list of priorities that the hypervisor has reserved for its own use. OPAL uses the priority 7 queue to automatically escalate interrupts for all other queues (DD2.X POWER9). So only priorities [0..6] are allowed for the guest. Extend the sPAPR IRQ backend with a new handler to populate the DT with the appropriate "interrupt-controller" node. Signed-off-by: Cédric Le Goater <clg@kaod.org> [dwg: Fix style nits] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: introduce a new machine IRQ backend for XIVECédric Le Goater2018-12-201-0/+2
| | | | | | | | | | | | | | | | The XIVE IRQ backend uses the same layout as the new XICS backend but covers the full range of the IRQ number space. The IRQ numbers for the CPU IPIs are allocated at the bottom of this space, below 4K, to preserve compatibility with XICS which does not use that range. This should be enough given that the maximum number of CPUs is 1024 for the sPAPR machine under QEMU. For the record, the biggest POWER8 or POWER9 system has a maximum of 1536 HW threads (16 sockets, 192 cores, SMT8). Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: introduce a spapr_irq_init() routineCédric Le Goater2018-12-201-0/+1
| | | | | | | | | Initialize the MSI bitmap from it as this will be necessary for the sPAPR IRQ backend for XIVE. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: increase the size of the IRQ number spaceCédric Le Goater2018-09-251-0/+1
| | | | | | | | | | | | | | | The new layout using static IRQ number does not leave much space to the dynamic MSI range, only 0x100 IRQ numbers. Increase the total number of IRQS for newer machines and introduce a legacy XICS backend for pre-3.1 machines to maintain compatibility. For the old backend, provide a 'nr_msis' value covering the full IRQ number space as it does not use the bitmap allocator to allocate MSI interrupt numbers. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: introduce a spapr_irq class 'nr_msis' attributeCédric Le Goater2018-09-251-0/+1
| | | | | | | | | | | | | | | | | | | | The number of MSI interrupts a sPAPR machine can allocate is in direct relation with the number of interrupts of the sPAPRIrq backend. Define statically this value at the sPAPRIrq class level and use it for the "ibm,pe-total-#msi" property of the sPAPR PHB. According to the PAPR specs, "ibm,pe-total-#msi" defines the maximum number of MSIs that are available to the PE. We choose to advertise the maximum number of MSIs that are available to the machine for simplicity of the model and to avoid segmenting the MSI interrupt pool which can be easily shared. If the pool limit is reached, it can be extended dynamically. Finally, remove XICS_IRQS_SPAPR which is now unused. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: introduce a IRQ controller backend to the machineCédric Le Goater2018-08-211-0/+22
| | | | | | | | | | | This proposal moves all the related IRQ routines of the sPAPR machine behind a sPAPR IRQ backend interface 'spapr_irq' to prepare for future changes. First of which will be to increase the size of the IRQ number space, then, will follow a new backend for the POWER9 XIVE IRQ controller. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr: introduce a fixed IRQ number spaceCédric Le Goater2018-08-211-0/+32
This proposal introduces a new IRQ number space layout using static numbers for all devices, depending on a device index, and a bitmap allocator for the MSI IRQ numbers which are negotiated by the guest at runtime. As the VIO device model does not have a device index but a "reg" property, we introduce a formula to compute an IRQ number from a "reg" value. It should minimize most of the collisions. The previous layout is kept in pre-3.1 machines raising the 'legacy_irq_allocation' machine class flag. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2025-01-03 17:24:03 +0100