diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2017-06-06 17:01:21 +1000 |
---|---|---|
committer | David Gibson <david@gibson.dropbear.id.au> | 2017-06-08 14:38:26 +1000 |
commit | 454b580ae9ae3e7722f1cd5f6da7bb479f86bbd8 (patch) | |
tree | be99fdac2cfa1b215b83f1110bc6947758b8cda0 /memory.c | |
parent | f224d35be9fb971bf64b569b99ce2a582156bbf2 (diff) | |
download | qemu-454b580ae9ae3e7722f1cd5f6da7bb479f86bbd8.zip |
spapr: Don't misuse DR-indicator in spapr_recover_pending_dimm_state()
With some combinations of migration and hotplug we can lost temporary state
indicating how many DRCs (guest side hotplug handles) are still connected
to a DIMM object in the process of removal. When we hit that situation
spapr_recover_pending_dimm_state() is used to scan more extensively and
work out the right number.
It does this using drc->indicator state to determine what state of
disconnection the DRC is in. However, this is not safe, because the
indicator state is guest settable - in fact it's more-or-less a purely
guest->host notification mechanism which should have no bearing on the
internals of hotplug state management.
So, replace the test for this with a test on drc->dev, which is a purely
qemu side managed variable, and updated the same BQL critical section as
the indicator state.
This does introduce an off-by-one change, because the indicator state was
updated before the call to spapr_lmb_release() on the current DRC, whereas
drc->dev is updated afterwards. That's corrected by always decrementing
the nr_lmbs value instead of only doing so in the case where we didn't
have to recover information.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Acked-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Diffstat (limited to 'memory.c')
0 files changed, 0 insertions, 0 deletions