From patchwork Wed Jul 7 15:49:32 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Klaus Jensen X-Patchwork-Id: 12362983 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB811C07E95 for ; Wed, 7 Jul 2021 15:53:11 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0462C61CBF for ; Wed, 7 Jul 2021 15:53:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0462C61CBF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=irrelevant.dk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:58094 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m19rJ-0002lH-Ss for qemu-devel@archiver.kernel.org; Wed, 07 Jul 2021 11:53:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46270) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m19o0-0008WF-9J; Wed, 07 Jul 2021 11:49:44 -0400 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:34615) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m19ny-0003EF-I2; Wed, 07 Jul 2021 11:49:44 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7238D3200919; Wed, 7 Jul 2021 11:49:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 07 Jul 2021 11:49:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irrelevant.dk; h=from:to:cc:subject:date:message-id:content-type:mime-version :content-transfer-encoding; s=fm3; bh=BoSJQgpDpThJHnbOl1S4Wcdg8u yckYgV0TgxSt67G0M=; b=YSrFhXB3vZYOtRtLZwziX3c0ZzVvwxicfpELbqlurH jE9hP6qFAp5pKgWxBfEa3YqSO0R7PC/EV4JgCpOXAl8ouvMHNulZw63dWLSb61SK CFDtXv2mKdWvVDMzIJNpyzA4agC4awizT2dGl3CKUp0W4oMM1QhcctSXeOSTdhf/ ZoVJk7wq4G9oFt1O1IZanU5F9aHzM9O9Mm1fC207SkxXTEE6XDAH9ydmtKcvJom+ q3iN31zcrfJMeHtCWdPGGvPYgqe611iPnK8qSmbGoDb4Z0hIhO6nslkN5SQVKXBe bmBvHhZ4wpp1i1hoIJBZFtlMdY/kDIKpNhHRKM8Vao8g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=BoSJQg pDpThJHnbOl1S4Wcdg8uyckYgV0TgxSt67G0M=; b=rqw0LG7tyROsLAHg3YMPi0 Y3e1J1qaUPZxFidPf2FqULc4pbb5lTN1m29Uqmu2CKfDBrmHeIoA92EttTd3peNI osGsG3Ml9xt3AqcPHvV49zjNID+ZTktwZNAFQdZh8+d50qYLGs950DY2bYuYVohF 78TxXkDtOgTu8bz03+LGBDF6DDxH3bc3qVTyPzOgWou30XtIsjV28smk1rlKQJPM ffoi10XfMNOWEeKXgZ53nvEsCj3Ew+L03WKYHESv171lQ/KpvquTZlnhdvSnj3uD 4+81rMjK8STWTK56EMJoPMXTxBOJDqRBiRfMPakK53hvhtoulZxuDkNVDgZAMO3Q == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtddvgdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkofgtggfgsehtqhertdertdejnecuhfhrohhmpefmlhgruhhsucfl vghnshgvnhcuoehithhssehirhhrvghlvghvrghnthdrughkqeenucggtffrrghtthgvrh hnpefhgeevkeeigfekvedvteejjeekkedugfdvheeijeffgfekffdvveelffetvdeghfen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehithhsse hirhhrvghlvghvrghnthdrughk X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Jul 2021 11:49:37 -0400 (EDT) From: Klaus Jensen To: qemu-devel@nongnu.org Subject: [PATCH v2 0/4] hw/nvme: fix controller hotplugging Date: Wed, 7 Jul 2021 17:49:32 +0200 Message-Id: <20210707154936.200166-1-its@irrelevant.dk> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 Received-SPF: pass client-ip=64.147.123.24; envelope-from=its@irrelevant.dk; helo=wout1-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Keith Busch , Klaus Jensen , Hannes Reinecke , qemu-block@nongnu.org, Klaus Jensen Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" From: Klaus Jensen Back in May, Hannes posted a fix[1] to re-enable NVMe PCI hotplug. We discussed a bit back and fourth and I mentioned that the core issue was an artifact of the parent/child relationship stemming from the qdev setup we have with namespaces attaching to controller through a qdev bus. The gist of this series is the fourth patch "hw/nvme: fix controller hot unplugging" which basically causes namespaces to be reassigned to a bus owned by the subsystem if the parent controller is linked to one. This fixes `device_del/add nvme` in such settings. Note, that in the case that there is no subsystem involved, nvme devices can be removed from the system with `device_del`, but this *will* cause the namespaces to be removed as well since there is no place (i.e. no subsystem) for them to "linger". And since this series does not add support for hotplugging nvme-ns devices, while an nvme device can be readded, no namespaces can. Support for hotplugging nvme-ns devices is present in [1], but I'd rather not add that since I think '-device nvme-ns' is already a bad design choice. Now, I do realize that it is not "pretty" to explicitly change the parent bus, so I do have a an RFC patch in queue that replaces the subsystem and namespace devices with objects, but keeps -device shims available for backwards compatibility. This approach will solve the problems properly and should be a better model. However, I don't believe it will make it for 6.1 and I'd really like to at least fix the unplugging for 6.1 and this gets the job done. [1]: 20210511073511.32511-1-hare@suse.de v2: - added R-b's by Hannes for patches 1 through 3 - simplified "hw/nvme: fix controller hot unplugging" Klaus Jensen (4): hw/nvme: remove NvmeCtrl parameter from ns setup/check functions hw/nvme: mark nvme-subsys non-hotpluggable hw/nvme: unregister controller with subsystem at exit hw/nvme: fix controller hot unplugging hw/nvme/nvme.h | 18 +++++++++------- hw/nvme/ctrl.c | 14 ++++++------ hw/nvme/ns.c | 55 +++++++++++++++++++++++++++++++----------------- hw/nvme/subsys.c | 9 ++++++++ 4 files changed, 63 insertions(+), 33 deletions(-)