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>
This commit is contained in:
parent
21f3f8db0e
commit
30bf9ed168
|
@ -1581,6 +1581,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);
|
||||
|
|
Loading…
Reference in a new issue