From nobody Wed Nov 5 17:40:55 2025 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 1496738247917925.5796775910453; Tue, 6 Jun 2017 01:37:27 -0700 (PDT) Received: from localhost ([::1]:36841 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dI9zO-0007RO-Tl for importer@patchew.org; Tue, 06 Jun 2017 04:37:22 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55005) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dI9ul-0003Ow-8e for qemu-devel@nongnu.org; Tue, 06 Jun 2017 04:32:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dI9uf-00021O-LM for qemu-devel@nongnu.org; Tue, 06 Jun 2017 04:32:34 -0400 Received: from ozlabs.org ([103.22.144.67]:54255) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dI9uf-00020f-5H; Tue, 06 Jun 2017 04:32:29 -0400 Received: by ozlabs.org (Postfix, from userid 1007) id 3whlL251WKz9s7p; Tue, 6 Jun 2017 18:32:26 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1496737946; bh=6Kz57DM9pjdomas671UTlPDTK9e33Uqecch6Z6mVnwo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cD0ZMpsqwkKiFTk2vf//n3upQeAdAe3jwHlNr7e5Pn0G9/PIzfLK4zvbEBKkZEZm/ Sq2db9WbG9OSeYLdblGUnETp7RyS6D5C/5rU8i1Dx9YGIjLwXMyyTX0BuOfyJu1bjJ eG4ybnJZRwrKUAroXD7X6hOb+qdo7zAdu26dOvA8= From: David Gibson To: mdroth@linux.vnet.ibm.com Date: Tue, 6 Jun 2017 18:32:18 +1000 Message-Id: <20170606083221.9299-5-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.9.4 In-Reply-To: <20170606083221.9299-1-david@gibson.dropbear.id.au> References: <20170606083221.9299-1-david@gibson.dropbear.id.au> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 103.22.144.67 Subject: [Qemu-devel] [PATCH 4/7] 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: lvivier@redhat.com, sursingh@redhat.com, groug@kaod.org, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, bharata@linux.vnet.ibm.com, 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 --- 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 671cdbb..e8cecaf 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -2683,7 +2683,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; @@ -2707,10 +2707,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