From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cA7qt-0000F5-OY for qemu-devel@nongnu.org; Thu, 24 Nov 2016 23:11:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cA7qq-00071X-JO for qemu-devel@nongnu.org; Thu, 24 Nov 2016 23:11:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45272) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cA7qq-00070w-DC for qemu-devel@nongnu.org; Thu, 24 Nov 2016 23:11:04 -0500 Date: Fri, 25 Nov 2016 06:11:01 +0200 From: "Michael S. Tsirkin" Message-ID: <20161125060705-mutt-send-email-mst@kernel.org> References: <1479802130-22640-1-git-send-email-peterx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1479802130-22640-1-git-send-email-peterx@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2] pci: relax pci_msi_get_message() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Xu Cc: qemu-devel@nongnu.org, david@gibson.dropbear.id.au On Tue, Nov 22, 2016 at 04:08:50PM +0800, Peter Xu wrote: > 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: >=20 > 6d17a01 vfio/pci: Fix regression in MSI routing configuration >=20 > However we encountered another case now with windows virtio driver and > reported (and possibly more): >=20 > http://bugs.debian.org/844361 >=20 > 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. >=20 > Reported-by: Maciej Kotli=C5=84ski > Signed-off-by: Peter Xu > --- > hw/pci/pci.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) >=20 > diff --git a/hw/pci/pci.c b/hw/pci/pci.c > index 24fae16..0cd2bb0 100644 > --- a/hw/pci/pci.c > +++ b/hw/pci/pci.c > @@ -2606,9 +2606,11 @@ MSIMessage pci_get_msi_message(PCIDevice *dev, i= nt vector) > } else if (msi_enabled(dev)) { > msg =3D 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. > + */ > + memset(&msg, 0, sizeof(msg)); > } > return msg; > } Looks like a hack to me. Even if callers happen to treat 0 message as a nop, there's no guarantee that's true for all platforms. Pls change pci_get_msi_message to return an error code, and fix callers to check that. > --=20 > 2.7.4