| commit | 30bf9ed1684da582e47ae004f8f3cf14fd6f39dd | |
| author | Cédric Le Goater <clg@kaod.org> | |
| Fri, 8 Sep 2017 14:33:43 +0000 (8 16:33 +0200) | ||
| committer | David Gibson <david@gibson.dropbear.id.au> | |
| Fri, 15 Sep 2017 00:29:48 +0000 (15 10:29 +1000) | ||
| tree | 4a6a2ced33aae0b25fd65b4eb68c7e25d20a55a5 | treesnapshot (tar.gz zip) |
| parent | 21f3f8db0e61884ca48e9969b0305d54f1efe24b | commitdiff |
spapr: fix CAS-generated reset
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>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
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>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
| hw/ppc/spapr_hcall.c | diffblobblamehistory |