qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 29/33] spapr, xics, xive: Move SpaprIrq::reset hook logic


From: David Gibson
Subject: Re: [PATCH v2 29/33] spapr, xics, xive: Move SpaprIrq::reset hook logic into activate/deactivate
Date: Mon, 30 Sep 2019 18:25:43 +1000
User-agent: Mutt/1.12.1 (2019-06-15)

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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]