On Mon, Sep 30, 2019 at 08:11:56AM +0200, Cédric Le Goater wrote: > On 27/09/2019 07:50, David Gibson wrote: > > 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. > > This is a 'critical' part which impacts all the migration cases: > > ic-mode=xics,xive,dual + kernel_irqchip=on/off + TCG
Yes... and?
> > To make this flow clearer, move the logic into the explicit backend
> > activate and deactivate hooks.
>
> I don't see where the hooks are called ?
spapr_irq_reset()
-> spapr_irq_update_active_intc()
-> set_active_intc()
-> activate/deactivate hooks
Similarly via spapr_irq_post_load().
I'm hoping to add one at CAS time to avoid the CAS reboot, too.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
