| Message ID | 20170908143344.12960-3-clg@kaod.org |
|---|---|
| State | New |
| Headers | show |
| Series | spapr: XIVE and CAS fixes | expand |
On Fri, Sep 08, 2017 at 04:33:43PM +0200, Cédric Le Goater wrote: > The OV5_MMU_RADIX_300 requires special handling in the CAS negotiation > process. It is cleared from the option vector of the guest before > evaluating the changes and re-added later. But, when testing for a > possible CAS reset : > > spapr->cas_reboot = spapr_ovec_diff(ov5_updates, > ov5_cas_old, spapr->ov5_cas); > > the bit OV5_MMU_RADIX_300 will each time be seen as removed from the > previous OV5 set, hence generating a reset loop. > > Fix this problem by also clearing the same bit in the ov5_cas_old set. > > Signed-off-by: Cédric Le Goater <clg@kaod.org> Kind of an ugly hack, but probably the easiest fix for now. Applied to ppc-for-2.11. > --- > hw/ppc/spapr_hcall.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c > index 07b3da8dc4cd..92f1e21358b8 100644 > --- a/hw/ppc/spapr_hcall.c > +++ b/hw/ppc/spapr_hcall.c > @@ -1575,6 +1575,13 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu, > * to worry about this for now. > */ > ov5_cas_old = spapr_ovec_clone(spapr->ov5_cas); > + > + /* also clear the radix/hash bit from the current ov5_cas bits to > + * be in sync with the newly ov5 bits. Else the radix bit will be > + * seen as being removed and this will generate a reset loop > + */ > + spapr_ovec_clear(ov5_cas_old, OV5_MMU_RADIX_300); > + > /* full range of negotiated ov5 capabilities */ > spapr_ovec_intersect(spapr->ov5_cas, spapr->ov5, ov5_guest); > spapr_ovec_cleanup(ov5_guest);
On 09/10/2017 05:17 AM, David Gibson wrote: > On Fri, Sep 08, 2017 at 04:33:43PM +0200, Cédric Le Goater wrote: >> The OV5_MMU_RADIX_300 requires special handling in the CAS negotiation >> process. It is cleared from the option vector of the guest before >> evaluating the changes and re-added later. But, when testing for a >> possible CAS reset : >> >> spapr->cas_reboot = spapr_ovec_diff(ov5_updates, >> ov5_cas_old, spapr->ov5_cas); >> >> the bit OV5_MMU_RADIX_300 will each time be seen as removed from the >> previous OV5 set, hence generating a reset loop. >> >> Fix this problem by also clearing the same bit in the ov5_cas_old set. >> >> Signed-off-by: Cédric Le Goater <clg@kaod.org> > > Kind of an ugly hack, yes. I lack context to fully understand why the guest radix option is handled that way. > but probably the easiest fix for now. Applied to ppc-for-2.11. Thanks, C. > >> --- >> hw/ppc/spapr_hcall.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c >> index 07b3da8dc4cd..92f1e21358b8 100644 >> --- a/hw/ppc/spapr_hcall.c >> +++ b/hw/ppc/spapr_hcall.c >> @@ -1575,6 +1575,13 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu, >> * to worry about this for now. >> */ >> ov5_cas_old = spapr_ovec_clone(spapr->ov5_cas); >> + >> + /* also clear the radix/hash bit from the current ov5_cas bits to >> + * be in sync with the newly ov5 bits. Else the radix bit will be >> + * seen as being removed and this will generate a reset loop >> + */ >> + spapr_ovec_clear(ov5_cas_old, OV5_MMU_RADIX_300); >> + >> /* full range of negotiated ov5 capabilities */ >> spapr_ovec_intersect(spapr->ov5_cas, spapr->ov5, ov5_guest); >> spapr_ovec_cleanup(ov5_guest); >
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c index 07b3da8dc4cd..92f1e21358b8 100644 --- a/hw/ppc/spapr_hcall.c +++ b/hw/ppc/spapr_hcall.c @@ -1575,6 +1575,13 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu, * to worry about this for now. */ ov5_cas_old = spapr_ovec_clone(spapr->ov5_cas); + + /* also clear the radix/hash bit from the current ov5_cas bits to + * be in sync with the newly ov5 bits. Else the radix bit will be + * seen as being removed and this will generate a reset loop + */ + spapr_ovec_clear(ov5_cas_old, OV5_MMU_RADIX_300); + /* full range of negotiated ov5 capabilities */ spapr_ovec_intersect(spapr->ov5_cas, spapr->ov5, ov5_guest); spapr_ovec_cleanup(ov5_guest);
The OV5_MMU_RADIX_300 requires special handling in the CAS negotiation process. It is cleared from the option vector of the guest before evaluating the changes and re-added later. But, when testing for a possible CAS reset : spapr->cas_reboot = spapr_ovec_diff(ov5_updates, ov5_cas_old, spapr->ov5_cas); the bit OV5_MMU_RADIX_300 will each time be seen as removed from the previous OV5 set, hence generating a reset loop. Fix this problem by also clearing the same bit in the ov5_cas_old set. Signed-off-by: Cédric Le Goater <clg@kaod.org> --- hw/ppc/spapr_hcall.c | 7 +++++++ 1 file changed, 7 insertions(+)