From nobody Mon Feb 9 10:37:47 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; dkim=fail spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1496986284370551.2964409679837; Thu, 8 Jun 2017 22:31:24 -0700 (PDT) Received: from localhost ([::1]:52680 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJCW1-00080p-Go for importer@patchew.org; Fri, 09 Jun 2017 01:31:21 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJCRx-0003vp-0I for qemu-devel@nongnu.org; Fri, 09 Jun 2017 01:27:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dJCRv-0006dS-KB for qemu-devel@nongnu.org; Fri, 09 Jun 2017 01:27:09 -0400 Received: from ozlabs.org ([2401:3900:2:1::2]:55473) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dJCRv-0006cA-7H; Fri, 09 Jun 2017 01:27:07 -0400 Received: by ozlabs.org (Postfix, from userid 1007) id 3wkW4c2fcYz9sNN; Fri, 9 Jun 2017 15:26:55 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1496986016; bh=z9T9L6pM01GMw5Y6ZHCS8zFc0ZBM5TGXIyGuhTpT014=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M57NDeNVx3p1wzWUbPvxU0y1mS/8gQfjkKux/5mMPujNN3hcZp4UB+2I5xNvPtR53 ygP5MxNEAsOS7mg/PBsX1bbk8j5/EqkPCa4ZuJcUx04Pv0EmM1wlT4Jtf1vYYBSvwd oyjm6NZpY1nbVHXR+bbCIaTzYPKmu2dzQguKjSlw= From: David Gibson To: peter.maydell@linaro.org Date: Fri, 9 Jun 2017 15:26:38 +1000 Message-Id: <20170609052652.23200-7-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.9.4 In-Reply-To: <20170609052652.23200-1-david@gibson.dropbear.id.au> References: <20170609052652.23200-1-david@gibson.dropbear.id.au> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2401:3900:2:1::2 Subject: [Qemu-devel] [PULL 06/20] spapr: Don't misuse DR-indicator in spapr_recover_pending_dimm_state() X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-devel@nongnu.org, sursingh@redhat.com, mdroth@linux.vnet.ibm.com, agraf@suse.de, qemu-ppc@nongnu.org, David Gibson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Reviewed-by: Michael Roth Acked-by: Michael Roth --- hw/ppc/spapr.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 9b7ae28..b2311dc 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -2676,7 +2676,7 @@ static sPAPRDIMMState *spapr_recover_pending_dimm_sta= te(sPAPRMachineState *ms, drc =3D spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, addr / SPAPR_MEMORY_BLOCK_SIZE); g_assert(drc); - if (drc->indicator_state !=3D SPAPR_DR_INDICATOR_STATE_INACTIVE) { + if (drc->dev) { avail_lmbs++; } addr +=3D SPAPR_MEMORY_BLOCK_SIZE; @@ -2700,10 +2700,11 @@ void spapr_lmb_release(DeviceState *dev) * during the unplug process. In this case recover it. */ if (ds =3D=3D NULL) { ds =3D spapr_recover_pending_dimm_state(spapr, PC_DIMM(dev)); - if (ds->nr_lmbs) { - return; - } - } else if (--ds->nr_lmbs) { + /* The DRC being examined by the caller at least must be counted */ + g_assert(ds->nr_lmbs); + } + + if (--ds->nr_lmbs) { return; } =20 --=20 2.9.4