From patchwork Tue Nov 22 07:48:52 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Peter Xu X-Patchwork-Id: 9440573 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 32A8C60237 for ; Tue, 22 Nov 2016 07:49:22 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2471928478 for ; Tue, 22 Nov 2016 07:49:22 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 170E02847A; Tue, 22 Nov 2016 07:49:22 +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 A907728478 for ; Tue, 22 Nov 2016 07:49:21 +0000 (UTC) Received: from localhost ([::1]:53822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c95pQ-00052l-Nr for patchwork-qemu-devel@patchwork.kernel.org; Tue, 22 Nov 2016 02:49:20 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c95p9-00052g-Il for qemu-devel@nongnu.org; Tue, 22 Nov 2016 02:49:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c95p6-0007RY-GF for qemu-devel@nongnu.org; Tue, 22 Nov 2016 02:49:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33660) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c95p6-0007PY-A2 for qemu-devel@nongnu.org; Tue, 22 Nov 2016 02:49:00 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3EA6B793C1; Tue, 22 Nov 2016 07:48:58 +0000 (UTC) Received: from pxdev.xzpeter.org.com (dhcp-14-171.nay.redhat.com [10.66.14.171]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAM7mtcN017228; Tue, 22 Nov 2016 02:48:56 -0500 From: Peter Xu To: qemu-devel@nongnu.org Date: Tue, 22 Nov 2016 15:48:52 +0800 Message-Id: <1479800932-16685-1-git-send-email-peterx@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 22 Nov 2016 07:48:58 +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] pci: relax pci_msi_get_message() 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: david@gibson.dropbear.id.au, peterx@redhat.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 We are very strict in the past getting MSIs from commit d1f6af6a1 ("kvm-irqchip: simplify kvm_irqchip_add_msi_route"), assuming that MSI should be configured before hand when fetching. When we have unrecognized configurations, we panic the system. However looks like this is too strict to be working on some platform, and issues occured. Firstly it's found on a ppc case and fixed by David in: 6d17a01 vfio/pci: Fix regression in MSI routing configuration However we encountered another case now with windows virtio driver and reported (and possibly more): http://bugs.debian.org/844361 To make every driver/hardware happy, let's loosen the rule and go back to the original behavior - instead of panic the system, when we try to fetch MSI without configured MSI/MSI-X system, we just provide an empty message to make drivers happy. Reported-by: Maciej Kotliński Signed-off-by: Peter Xu --- hw/pci/pci.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/hw/pci/pci.c b/hw/pci/pci.c index 24fae16..bda5211 100644 --- a/hw/pci/pci.c +++ b/hw/pci/pci.c @@ -2606,9 +2606,11 @@ MSIMessage pci_get_msi_message(PCIDevice *dev, int vector) } else if (msi_enabled(dev)) { msg = msi_get_message(dev, vector); } else { - /* Should never happen */ - error_report("%s: unknown interrupt type", __func__); - abort(); + /* + * Device is not configured with MSI/MSI-X yet, let's provide + * an empty message to make all device drivers happy. + */ + bzero(&msg, sizeof(msg)); } return msg; }