[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: |
Tue, 1 Oct 2019 13:07:47 +1000 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
On Mon, Sep 30, 2019 at 09:29:14PM +0200, Cédric Le Goater wrote:
> On 30/09/2019 10:25, David Gibson wrote:
> > 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?
>
> and it's fragile.
How so? Explicitly having logic for when an intc becomes active or
inactive, and having a single callsite which does that and updates the
active controller seems less fragile to me. At least compared to
having the update to the active controller (implicit in changing the
CAS vector) and the logic to get the controllers ready for being
active/inactive in totally different places and relying on the fact
they both only happen at reset for them to travel together.
>
> >>> 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.
>
> OK. I think the first 22 patches are ready, just some minor comments
> if I am correct. Could you merge them ?
I might repost first, because one of the changes Greg suggested to
error handling caused a larger than expected number of ripple on
fixes.
--
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
- [PATCH v2 27/33] spapr, xics, xive: Match signatures for XICS and XIVE KVM connect routines, (continued)
- [PATCH v2 27/33] spapr, xics, xive: Match signatures for XICS and XIVE KVM connect routines, David Gibson, 2019/09/27
- [PATCH v2 28/33] spapr: Remove SpaprIrq::init_kvm hook, David Gibson, 2019/09/27
- [PATCH v2 29/33] spapr, xics, xive: Move SpaprIrq::reset hook logic into activate/deactivate, David Gibson, 2019/09/27
- Re: [PATCH v2 29/33] spapr, xics, xive: Move SpaprIrq::reset hook logic into activate/deactivate, Cédric Le Goater, 2019/09/30
- Re: [PATCH v2 29/33] spapr, xics, xive: Move SpaprIrq::reset hook logic into activate/deactivate, David Gibson, 2019/09/30
- Re: [PATCH v2 29/33] spapr, xics, xive: Move SpaprIrq::reset hook logic into activate/deactivate, Cédric Le Goater, 2019/09/30
- Re: [PATCH v2 29/33] spapr, xics, xive: Move SpaprIrq::reset hook logic into activate/deactivate,
David Gibson <=
[PATCH v2 22/33] spapr, xics, xive: Move irq claim and free from SpaprIrq to SpaprInterruptController, David Gibson, 2019/09/27
Re: [PATCH v2 22/33] spapr, xics, xive: Move irq claim and free from SpaprIrq to SpaprInterruptController, Cédric Le Goater, 2019/09/30
[PATCH v2 26/33] spapr, xics, xive: Move dt_populate from SpaprIrq to SpaprInterruptController, David Gibson, 2019/09/27
[PATCH v2 32/33] spapr: Move SpaprIrq::nr_xirqs to SpaprMachineClass, David Gibson, 2019/09/27