From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 37D45C433F5 for ; Mon, 9 May 2022 14:35:02 +0000 (UTC) Received: from localhost ([::1]:46684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1no4TV-0003tz-8s for qemu-devel@archiver.kernel.org; Mon, 09 May 2022 10:35:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38584) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1no4EN-0002Hj-4z; Mon, 09 May 2022 10:19:25 -0400 Received: from mga05.intel.com ([192.55.52.43]:24288) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1no4EL-0001AQ-HO; Mon, 09 May 2022 10:19:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652105961; x=1683641961; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=wCnjRNxx0aBPKHmxBrCa2GOKDCDydqbCCvB5XSuBI9k=; b=PptGfoDanHtObCht+6G/KMh2CPzI2KsnNa9MiNYXtVK0PZ6EnNGM+eWf l6TGjXfNdJJxeNjxVUSwsFBN61HMDDlmFmrBWESanyFmMwJXDltdhufrY UcIptugcSnx0bWSJ8ErGGgg2NZKZS/e3kGNAmRzPK+p1WiqAoXTihCOw8 YoeS7fUXjwQWqjZ0Dop4Cb6ADRnvV5PeCb5+hWhs/jKoWvW0HtLp8U123 Za+G5xbIITSQ7vfR8QTCJzAI2Z2Q9+d6wVZrounbuF0DjSmXFDxu6x9bm 6h/IVlEEU4bjBRilOKOuSx4MJ+sEMJhEoV3e8BZqzRSYooRSwyRFUocdd Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10342"; a="355490904" X-IronPort-AV: E=Sophos;i="5.91,211,1647327600"; d="scan'208";a="355490904" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 May 2022 07:19:19 -0700 X-IronPort-AV: E=Sophos;i="5.91,211,1647327600"; d="scan'208";a="622987375" Received: from lmaniak-dev.elements.local ([10.55.249.72]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 May 2022 07:19:16 -0700 From: Lukasz Maniak To: qemu-devel@nongnu.org Cc: qemu-block@nongnu.org, ani@anisinha.ca, armbru@redhat.com, f4bug@amsat.org, fam@euphon.net, hreitz@redhat.com, imammedo@redhat.com, its@irrelevant.dk, kbusch@kernel.org, k.jensen@samsung.com, kwolf@redhat.com, lukasz.gieryk@linux.intel.com, lukasz.maniak@linux.intel.com, marcel.apfelbaum@gmail.com, mst@redhat.com, stefanha@redhat.com, xypron.glpk@gmx.de Subject: [PATCH v8 11/12] hw/nvme: Update the initalization place for the AER queue Date: Mon, 9 May 2022 16:16:19 +0200 Message-Id: <20220509141620.3868733-12-lukasz.maniak@linux.intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220509141620.3868733-1-lukasz.maniak@linux.intel.com> References: <20220509141620.3868733-1-lukasz.maniak@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Received-SPF: none client-ip=192.55.52.43; envelope-from=lukasz.maniak@linux.intel.com; helo=mga05.intel.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" From: Łukasz Gieryk This patch updates the initialization place for the AER queue, so it’s initialized once, at controller initialization, and not every time controller is enabled. While the original version works for a non-SR-IOV device, as it’s hard to interact with the controller if it’s not enabled, the multiple reinitialization is not necessarily correct. With the SR/IOV feature enabled a segfault can happen: a VF can have its controller disabled, while a namespace can still be attached to the controller through the parent PF. An event generated in such case ends up on an uninitialized queue. While it’s an interesting question whether a VF should support AER in the first place, I don’t think it must be answered today. Signed-off-by: Łukasz Gieryk Reviewed-by: Klaus Jensen Acked-by: Michael S. Tsirkin --- hw/nvme/ctrl.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c index 247c09882dd..b0862b1d96c 100644 --- a/hw/nvme/ctrl.c +++ b/hw/nvme/ctrl.c @@ -6326,8 +6326,6 @@ static int nvme_start_ctrl(NvmeCtrl *n) nvme_set_timestamp(n, 0ULL); - QTAILQ_INIT(&n->aer_queue); - nvme_select_iocs(n); return 0; @@ -6987,6 +6985,7 @@ static void nvme_init_state(NvmeCtrl *n) n->features.temp_thresh_hi = NVME_TEMPERATURE_WARNING; n->starttime_ms = qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL); n->aer_reqs = g_new0(NvmeRequest *, n->params.aerl + 1); + QTAILQ_INIT(&n->aer_queue); list->numcntl = cpu_to_le16(max_vfs); for (i = 0; i < max_vfs; i++) { -- 2.25.1