]> git.proxmox.com Git - mirror_qemu.git/commit - hw/ppc/spapr.c
spapr: Don't misuse DR-indicator in spapr_recover_pending_dimm_state()
authorDavid Gibson <david@gibson.dropbear.id.au>
Tue, 6 Jun 2017 07:01:21 +0000 (17:01 +1000)
committerDavid Gibson <david@gibson.dropbear.id.au>
Thu, 8 Jun 2017 04:38:26 +0000 (14:38 +1000)
commit454b580ae9ae3e7722f1cd5f6da7bb479f86bbd8
treebe99fdac2cfa1b215b83f1110bc6947758b8cda0
parentf224d35be9fb971bf64b569b99ce2a582156bbf2
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>
hw/ppc/spapr.c