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 <c...@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); >
