summaryrefslogtreecommitdiff
path: root/tests/libqtest.c
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2017-06-06 17:01:21 +1000
committerDavid Gibson <david@gibson.dropbear.id.au>2017-06-08 14:38:26 +1000
commit454b580ae9ae3e7722f1cd5f6da7bb479f86bbd8 (patch)
treebe99fdac2cfa1b215b83f1110bc6947758b8cda0 /tests/libqtest.c
parentf224d35be9fb971bf64b569b99ce2a582156bbf2 (diff)
downloadqemu-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 'tests/libqtest.c')
0 files changed, 0 insertions, 0 deletions