From nobody Tue Feb 10 04:17:28 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.zohomail.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 1499839136718828.64210881764; Tue, 11 Jul 2017 22:58:56 -0700 (PDT) Received: from localhost ([::1]:50524 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVAfn-0005WX-Db for importer@patchew.org; Wed, 12 Jul 2017 01:58:55 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49446) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVAb1-0001X3-30 for qemu-devel@nongnu.org; Wed, 12 Jul 2017 01:54:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVAaw-0004ub-HX for qemu-devel@nongnu.org; Wed, 12 Jul 2017 01:53:59 -0400 Received: from ozlabs.org ([103.22.144.67]:46311) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dVAaw-0004uB-5g; Wed, 12 Jul 2017 01:53:54 -0400 Received: by ozlabs.org (Postfix, from userid 1007) id 3x6p5s43wGz9sRg; Wed, 12 Jul 2017 15:53:21 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1499838801; bh=1OFsIIRkliGBxVZDaWKwzYpZ6hW1lRGEe+mU3t1FOFY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=d2xEepAJt9/YwLpALq7OiP5DIJQvMDwvXwgk+nZk584lRtl4W7I9Mf7Nv7303T2oz hHiv8XtI2rzkXxwL6In3X4iV+QVPzyUQ/UEh1J7/+HsDUuK/ap7IJ0LCAkd1A6Xu45 1GQV0i5ZpdrenR66i+judkiA7EKc7frUKHm9jPmo= From: David Gibson To: mdroth@linux.vnet.ibm.com, groug@kaod.org, danielhb@linux.vnet.ibm.com Date: Wed, 12 Jul 2017 15:53:11 +1000 Message-Id: <20170712055317.26225-3-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.9.4 In-Reply-To: <20170712055317.26225-1-david@gibson.dropbear.id.au> References: <20170712055317.26225-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] [PATCHv2 2/8] spapr: Remove 'awaiting_allocation' DRC flag 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, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, sjitindarsingh@gmail.com, 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" The awaiting_allocation flag in the DRC was introduced by aab9913 "spapr_drc: Prevent detach racing against attach for CPU DR", allegedly to prevent a guest crash on racing attach and detach. Except.. information from the BZ actually suggests a qemu crash, not a guest crash. And there shouldn't be a problem here anyway: if the guest has already moved the DRC away from UNUSABLE state, the detach would already be deferred, and if it hadn't it should be safe to detach it (the guest should fail gracefully when it attempts to change the allocation state). I think this was probably just a bandaid for some other problem in the state management. So, remove awaiting_allocation and associated code. Signed-off-by: David Gibson Reviewed-by: Greg Kurz Reviewed-by: Laurent Vivier Tested-by: Greg Kurz --- hw/ppc/spapr_drc.c | 25 +++---------------------- include/hw/ppc/spapr_drc.h | 1 - 2 files changed, 3 insertions(+), 23 deletions(-) diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c index 9b07f80..89ba3d6 100644 --- a/hw/ppc/spapr_drc.c +++ b/hw/ppc/spapr_drc.c @@ -170,19 +170,13 @@ static uint32_t drc_set_usable(sPAPRDRConnector *drc) if (!drc->dev) { return RTAS_OUT_NO_SUCH_INDICATOR; } - if (drc->awaiting_release && drc->awaiting_allocation) { - /* kernel is acknowledging a previous hotplug event - * while we are already removing it. - * it's safe to ignore awaiting_allocation here since we know the - * situation is predicated on the guest either already having done - * so (boot-time hotplug), or never being able to acquire in the - * first place (hotplug followed by immediate unplug). - */ + if (drc->awaiting_release) { + /* Don't allow the guest to move a device away from UNUSABLE + * state when we want to unplug it */ return RTAS_OUT_NO_SUCH_INDICATOR; } =20 drc->allocation_state =3D SPAPR_DR_ALLOCATION_STATE_USABLE; - drc->awaiting_allocation =3D false; =20 return RTAS_OUT_SUCCESS; } @@ -357,10 +351,6 @@ void spapr_drc_attach(sPAPRDRConnector *drc, DeviceSta= te *d, void *fdt, drc->fdt =3D fdt; drc->fdt_start_offset =3D fdt_start_offset; =20 - if (spapr_drc_type(drc) !=3D SPAPR_DR_CONNECTOR_TYPE_PCI) { - drc->awaiting_allocation =3D true; - } - object_property_add_link(OBJECT(drc), "device", object_get_typename(OBJECT(drc->dev)), (Object **)(&drc->dev), @@ -398,12 +388,6 @@ void spapr_drc_detach(sPAPRDRConnector *drc, DeviceSta= te *d, Error **errp) return; } =20 - if (drc->awaiting_allocation) { - drc->awaiting_release =3D true; - trace_spapr_drc_awaiting_allocation(spapr_drc_index(drc)); - return; - } - spapr_drc_release(drc); } =20 @@ -426,8 +410,6 @@ void spapr_drc_reset(sPAPRDRConnector *drc) spapr_drc_release(drc); } =20 - drc->awaiting_allocation =3D false; - if (drc->dev) { /* A device present at reset is coldplugged */ drc->isolation_state =3D SPAPR_DR_ISOLATION_STATE_UNISOLATED; @@ -493,7 +475,6 @@ static const VMStateDescription vmstate_spapr_drc =3D { VMSTATE_UINT32(dr_indicator, sPAPRDRConnector), VMSTATE_BOOL(configured, sPAPRDRConnector), VMSTATE_BOOL(awaiting_release, sPAPRDRConnector), - VMSTATE_BOOL(awaiting_allocation, sPAPRDRConnector), VMSTATE_END_OF_LIST() } }; diff --git a/include/hw/ppc/spapr_drc.h b/include/hw/ppc/spapr_drc.h index 715016b..18a196e 100644 --- a/include/hw/ppc/spapr_drc.h +++ b/include/hw/ppc/spapr_drc.h @@ -200,7 +200,6 @@ typedef struct sPAPRDRConnector { sPAPRConfigureConnectorState *ccs; =20 bool awaiting_release; - bool awaiting_allocation; =20 /* device pointer, via link property */ DeviceState *dev; --=20 2.9.4