[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 08/22] ppc/xics: use the QOM inter
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 08/22] ppc/xics: use the QOM interface to resend irqs |
Date: |
Mon, 27 Feb 2017 11:37:06 +1100 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
On Fri, Feb 24, 2017 at 06:34:06PM +0100, Cédric Le Goater wrote:
> >>> @@ -592,10 +593,11 @@ static void ics_simple_reset(DeviceState *dev)
> >>>
> >>> static int ics_simple_post_load(ICSState *ics, int version_id)
> >>> {
> >>> + XICSInterface *xi = XICS_INTERFACE(qdev_get_machine());
> >>> int i;
> >>>
> >>> for (i = 0; i < ics->xics->nr_servers; i++) {
> >>> - icp_resend(&ics->xics->ss[i]);
> >>> + icp_resend(xi, &ics->xics->ss[i]);
> >>> }
> >>
> >> This resend triggering needs to get moved to the xics interface
> >> implementor - i.e. the machine. It's actually already broken right
> >> now, since it incorrectly relies on the ordering of the ics and icp
> >> restore during migration.
> >
> > I'm adding a icp_resend() handler in patch 12 and using it patch 14.
> > Maybe we can move the post_load() handler out of ICS simple now ?
>
> Could you give me a little more info on what should be done ? I lack
> context on this problem.
>
> So should we call :
>
> ICPState *ss = opaque;
> ICPStateClass *info = ICP_GET_CLASS(ss);
>
> if (info->post_load) {
> return info->post_load(ss, version_id);
> }
>
> and then
>
> ICSState *ics = opaque;
> ICSStateClass *info = ICS_BASE_GET_CLASS(ics);
>
> if (info->post_load) {
> return info->post_load(ics, version_id);
> }
>
> from spapr_post_load() ?
Uh.. now I'm trying to remember what the correct order is. Any part
of the post_load which is entirely local to the ics or icp, and
doesn't communicate with the other part should remain in a local
post-load handler.
The part of the resend which involves interaction between ics and icp
should move to the mahine. Because the ics and icp are both
descendents of the machine, the migration core does guarantee their
local post_lodas will run before the machine's post-load. At the
moment however, we require either the ics post_loads to run before the
icp or the other way around - I forget which. Because these are
"cousin" objects, that order is not guaranteed by the migration core.
--
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
- Re: [Qemu-devel] [PATCH v2 05/22] ppc/xics: introduce a QOM interface to handle ICSs, (continued)
- [Qemu-devel] [PATCH v2 06/22] ppc/xics: use the QOM interface under the sPAPR machine, Cédric Le Goater, 2017/02/16
- [Qemu-devel] [PATCH v2 07/22] ppc/xics: use the QOM interface to get irqs, Cédric Le Goater, 2017/02/16
- [Qemu-devel] [PATCH v2 08/22] ppc/xics: use the QOM interface to resend irqs, Cédric Le Goater, 2017/02/16
- [Qemu-devel] [PATCH v2 09/22] ppc/xics: remove xics_find_source(), Cédric Le Goater, 2017/02/16
- [Qemu-devel] [PATCH v2 10/22] ppc/xics: register the reset handler of ICS objects, Cédric Le Goater, 2017/02/16
- [Qemu-devel] [PATCH v2 11/22] ppc/xics: remove the XICS list of ICS, Cédric Le Goater, 2017/02/16
- [Qemu-devel] [PATCH v2 12/22] ppc/xics: extend the QOM interface to handle ICPs, Cédric Le Goater, 2017/02/16