From patchwork Mon Nov 20 14:22:16 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ladi Prosek X-Patchwork-Id: 10066609 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0EFF4602B7 for ; Mon, 20 Nov 2017 14:23:26 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EF6E5292EA for ; Mon, 20 Nov 2017 14:23:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E4360292EF; Mon, 20 Nov 2017 14:23:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 7E229292EA for ; Mon, 20 Nov 2017 14:23:25 +0000 (UTC) Received: from localhost ([::1]:57594 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGmyp-0008Cz-Lz for patchwork-qemu-devel@patchwork.kernel.org; Mon, 20 Nov 2017 09:23:23 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGmxz-0008Cp-T9 for qemu-devel@nongnu.org; Mon, 20 Nov 2017 09:22:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGmxw-00010I-Oy for qemu-devel@nongnu.org; Mon, 20 Nov 2017 09:22:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49584) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eGmxw-000102-IT for qemu-devel@nongnu.org; Mon, 20 Nov 2017 09:22:28 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 96A6E7E390; Mon, 20 Nov 2017 14:22:27 +0000 (UTC) Received: from dhcp-1-107.brq.redhat.com (ovpn-204-197.brq.redhat.com [10.40.204.197]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0D9D34DC57; Mon, 20 Nov 2017 14:22:18 +0000 (UTC) From: Ladi Prosek To: qemu-devel@nongnu.org Date: Mon, 20 Nov 2017 15:22:16 +0100 Message-Id: <20171120142216.17832-1-lprosek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 20 Nov 2017 14:22:27 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH] msix: don't mask already masked vectors on reset 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: marcel@redhat.com, geoff@hostfission.com, mst@redhat.com Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP msix_mask_all() is supposed to invoke the release vector notifier if the state of the respective vector changed from unmasked or masked. The way it's currently called from msix_reset(), though, may result in calling the release notifier even if the vector is already masked. 1) msix_reset() clears out the msix_cap field and the msix_table. 2) msix_mask_all() runs with was_masked=false for all vectors because of 1), which results in calling the release notifier on all vectors. 3) if msix_reset() is subsequently called again, it goes through the same steps and calls the release notifier on all vectors again. This commit moves msix_mask_all() up so it runs before the device state is lost. And it adds a call to msix_update_function_masked() so that the device remembers that MSI-X is masked. This is likely a low impact issue, found while debugging an already broken device. It is however easy to fix and the expectation that the use and release notifier invocations are always balanced is very natural. Signed-off-by: Ladi Prosek --- hw/pci/msix.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/pci/msix.c b/hw/pci/msix.c index c944c02135..34656de9b0 100644 --- a/hw/pci/msix.c +++ b/hw/pci/msix.c @@ -500,11 +500,12 @@ void msix_reset(PCIDevice *dev) return; } msix_clear_all_vectors(dev); + msix_mask_all(dev, dev->msix_entries_nr); dev->config[dev->msix_cap + MSIX_CONTROL_OFFSET] &= ~dev->wmask[dev->msix_cap + MSIX_CONTROL_OFFSET]; memset(dev->msix_table, 0, dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE); memset(dev->msix_pba, 0, QEMU_ALIGN_UP(dev->msix_entries_nr, 64) / 8); - msix_mask_all(dev, dev->msix_entries_nr); + msix_update_function_masked(dev); } /* PCI spec suggests that devices make it possible for software to configure